Repeated XML Artifact Identity Fix

Claim

The Web upload failure PROCESSING_SOURCE_INVALID: processing source object is unavailable was caused by database content deduplication reusing an older run's artifact row. Migration 011 fixes that failure. A post-fix real upload now reaches SuperAgent, but the wider E2E remains blocked because the successful remote run did not call the direct-result MCP tool.

Runtime Evidence

Four repeated submissions created processing runs 17 through 20 between 20:29 and 20:32.
Each run had a queued attempt and an issued, unconsumed direct-MCP grant, but no remote run identifier and no result submission.
All four new runs pointed to the same opera_xml artifact row and therefore to the committed object key belonging to run 16.
OssProcessingMessageBuilder correctly requires the current job_id to be a path segment in the source object key, so it rejected those cross-run references before Open Agent dispatch.
The browser rendered the safe error text but incorrectly described the task as not created even though the database registration and grant already existed. That display issue remains separate from the identity fix.

Root Cause

Migration 008 imposed UNIQUE (artifact_kind, sha256), and PostgresIngestionRepository._ensure_artifact() looked up artifacts only by those two content fields. Reusing the same XML bytes in a new run therefore reused the old row and old job-scoped OSS key. This contradicted the intended rule that equal content may be processed in independent run/attempt identities.

Change

Migration 011 replaces the content uniqueness constraint with a non-unique lookup index. The existing storage-identity unique index remains authoritative.
_ensure_artifact() now finds an artifact by provider, bucket alias, object key and null object version, then verifies all immutable metadata before reuse.
Three repository regressions cover new-object insertion for equal content, exact storage-identity reuse and metadata conflict rejection.
Two migration regressions cover the forward shape and the guarded rollback refusal after repeated content exists.

Verification

57 targeted ingestion, direct-ingestion, processing and Web tests passed.
The complete suite passed 269 tests with 2 expected environment skips.
An up/down transaction rehearsal passed against booking_test.
Migration 011 was formally applied; artifact row count remained 12 and the expected non-unique lookup index replaced the content uniqueness constraint.
The controlled 8765 service was restarted and reported all database, processing and writeback health gates as ready.
The user-authorized 0721.XML was submitted through the real ARR session/CSRF upload endpoint as job arrjob-51284ae50150454f9c085b461be7f0d8. Its new source key contains that job identity, and two independent opera_xml artifact rows now exist for the equal content.
Remote run 3e17e1d3-3b06-4e9b-b008-e231770618b2 started successfully and the Open Agent API reports success with no platform error. It resolved the intended Profile and current enterprise MCP configuration version 53.
After the remote terminal state and an additional propagation window, the grant remained unconsumed, no result submission or Finance version existed, and the grant later expired. Therefore this run proves upload/dispatch but not MCP/Finance completion.
The authenticated Ops page could be opened, but structured log reads timed out twice. Exact Agent-step diagnosis requires the exported full run log; no further upload should be attempted until that log is reviewed.

Staleness Trigger

Reverify after changes to artifact identity schema, PostgresIngestionRepository._ensure_artifact(), object-key policy, or the active 8765 runtime.

3.7 KiB Raw Blame History