Recover Rekor duplicate-entry conflicts by default

[lodekeeper]

Summary

npm provenance publishing can fail with:

TLOG_CREATE_ENTRY_ERROR error creating tlog entry - (409) an equivalent entry already exists in the transparency log

This appears to be a retry-after-success path. Rekor accepts and commits the create-entry request, but the client times out, receives a transient network failure, or retries after a retryable response. The retry submits the same equivalent entry, Rekor correctly returns 409, and the signing flow treats that as fatal.

Current behavior

TLogClient defaults fetchOnConflict to false:

this.fetchOnConflict = options.fetchOnConflict ?? false;

High-level sigstore.attest() / npm provenance callers usually do not set this option directly, so a 409 from an already-created Rekor entry becomes TLOG_CREATE_ENTRY_ERROR instead of using the existing recovery path.

Expected behavior

When Rekor returns a 409 with a location for an equivalent existing entry, the default behavior should fetch the existing entry and continue. The existing entry is the entry the client needs in the Sigstore bundle, so this makes the create-entry operation idempotent from the caller's perspective while preserving provenance.

Callers that need fatal conflict behavior can still pass fetchOnConflict: false explicitly.

Downstream reports

Similar downstream failures and analyses:

• Release npm en échec sur cdtn-utils (Sigstore/Rekor TLOG 409) SocialGouv/code-du-travail-numerique#7419: Release npm en échec sur cdtn-utils (Sigstore/Rekor TLOG 409) SocialGouv/code-du-travail-numerique#7419
• Release pipeline: detect & prevent git-ahead-of-npm drift (post-publish verification + graceful Rekor 409) apify/apify-shared-js#649: Release pipeline: detect & prevent git-ahead-of-npm drift (post-publish verification + graceful Rekor 409) apify/apify-shared-js#649
• chore: handle Rekor 409 conflict during npm provenance publish ChainSafe/lodestar#9703: chore: handle Rekor 409 conflict during npm provenance publish ChainSafe/lodestar#9703

Proposed fix

Default TLogClient to fetchOnConflict: true, while preserving explicit fetchOnConflict: false for callers that want conflicts to remain fatal.

[bdehamer]

@lodekeeper Thanks for the feedback.

I think this is a reasonable change, though one I'll probably wait to merge until our next major release -- given that it changes the behavior of a public API and this library has consumers beyond the npm CLI, I don't want to make a breaking change w/o a major version bump.

[matthewkeil]

I think this is a reasonable change, though one I'll probably wait to merge until our next major release -- given that it changes the behavior of a public API and this library has consumers beyond the npm CLI, I don't want to make a breaking change w/o a major version bump.

Thanks @bdehamer !!! Do you know about when you will release the next version?

[bdehamer]

Historically, we've been rolling a new major version anytime we drop support for an EOL Node version. So, at the latest, we'd have a major version bump in May 2027 when Node 22 goes out of support.

However, we're likely to tackle some major refactoring before then in support of the post-quantum cryptography work that is currently underway in Sigstore. I don't have any specific dates for that at this time.

[bdehamer]

In the meantime, something we could consider is setting fetchOnConflict to true in npm itself. Seems that would give you the behavior you're after w/o a breaking change for all consumers of the library.

[lodekeeper]

Thanks @bdehamer — waiting for the next major to change the default in sigstore-js makes sense given it's a public-API change with consumers beyond the npm CLI.

No urgency on our end: our publish-dev flow isn't currently blocked (recent runs are green) and we have a local safety-net patch staged, so we're happy to wait for the major.

The fetchOnConflict: true in the npm CLI idea is a good interim path — it'd make provenance publishing idempotent for everyone hitting this 409, not just us. Could be worth raising with the npm CLI team separately. Appreciate you thinking it through.