add-project: first-use fails — isNotFound() regex misses S3 "does not exist" message (NoSuchKey treated as fatal)

[marcusrbrown]

Summary

On a freshly deployed gateway (v0.46.2), the first-ever /fro-bot add-project <url> always fails with "Internal error checking existing bindings. Please try again." Retrying does not help — it fails identically every time, because the daemon errors out before it ever writes the first binding. This is a deterministic first-use deadlock for add-project on any new gateway.

Reproduction

1. Deploy a fresh gateway with an empty object-store bindings prefix (zero bindings).
2. In the guild, run /fro-bot add-project https://github.com/owner/repo.
3. The command passes URL validation, enters PRE_FLIGHT, and aborts with "Internal error checking existing bindings."

Daemon logs

{"level":"info","phase":"PRE_FLIGHT","outcome":"start","msg":"add-project phase"}
{"level":"warn","errorCode":"NoSuchKey","errorName":"NoSuchKey","httpStatusCode":404,"message":"The specified key does not exist.","msg":"Object store getObject failed"}
{"level":"error","phase":"PRE_FLIGHT","errorKind":"Object store getObject failed: The specified key does not exist.","msg":"add-project: store error during pre-flight lookup"}

The 404 NoSuchKey is a valid S3 response — it confirms object-store credentials, connectivity, and the egress allowlist all work. The binding key simply doesn't exist yet because this is the first add-project.

Root cause

packages/gateway/src/bindings/store.ts classifies "key absent" via:

function isNotFound(error: Error): boolean {
  return /not.?found|no.?such.?key|404/i.test(error.message)
}

But the error reaching this check has the message produced by the object-store adapter:

Object store getObject failed: The specified key does not exist.

That string contains none of not found, no such key, or 404 (AWS's human-readable message is "The specified key does not exist."; NoSuchKey is the SDK error code, not the message). So isNotFound() returns false, the absent key is treated as a fatal store failure, and the pre-flight lookup aborts instead of proceeding to create the first binding.

Verified empirically:

/not.?found|no.?such.?key|404/i.test("Object store getObject failed: The specified key does not exist.")
// => false   (bug: expected 404 treated as fatal)

Suggested fix

Smallest change — also match the AWS message text:

function isNotFound(error: Error): boolean {
  return /not.?found|no.?such.?key|does.?not.?exist|404/i.test(error.message)
}

More robust — preserve and check the SDK error code (NoSuchKey) directly in the object-store adapter, falling back to the message regex for non-AWS S3-compatible stores. Matching on the code avoids future drift if a provider's message wording differs.

Affected versions

Present in v0.46.2 and still present on the v0.47.0 line (same isNotFound implementation). Any deployment whose object store returns the AWS-style "The specified key does not exist." message is affected; the first add-project can never succeed until this is patched.

[fro-bot]

Triage: confirmed bug — isNotFound() regex misses the AWS "does not exist" message

I reviewed packages/gateway/src/bindings/store.ts at the current main HEAD and reproduced the root cause empirically. The report is accurate.

Summary

On a fresh gateway, the first /fro-bot add-project <url> aborts in PRE_FLIGHT with "Internal error checking existing bindings." The pre-flight lookup calls getBindingByRepo(), which relies on isNotFound() to translate a missing-key 404 into ok(null) (key absent → proceed to create the first binding). For object stores that return AWS's human-readable message "The specified key does not exist.", isNotFound() returns false, so the absent key is misclassified as a fatal StoreError and the flow aborts. Because the daemon errors before writing the first binding, retries fail identically — a deterministic first-use deadlock.

Verified in source (packages/gateway/src/bindings/store.ts:43-45)

function isNotFound(error: Error): boolean {
  return /not.?found|no.?such.?key|404/i.test(error.message)
}

This same predicate gates the not-found path in getBindingByRepo (line 176), getBindingByChannelId (lines 203, 225), and listBindings (line 255) — so the bug affects every read path, not just add-project pre-flight.

Empirical reproduction

/not.?found|no.?such.?key|404/i.test("Object store getObject failed: The specified key does not exist.")
// => false   (bug: a valid 404 is treated as fatal)

The adapter wraps the SDK error into the message Object store getObject failed: The specified key does not exist.. That string contains none of not found, no such key, or 404 — the NoSuchKey token is the SDK error code, not part of the .message text the regex inspects.

Note: this CI checkout only materialized packages/gateway/src/bindings/; the @fro-bot/runtime object-store adapter and the binding test files were not present in the workspace, so I could not run the suite or read the exact adapter wrapping line. The regex behavior above is verified directly; the adapter message string is taken from the daemon logs in the report.

Recommended fix

Two layers, smallest-first:

1. Message regex (minimal, unblocks all affected deployments). Add the AWS phrasing:

   function isNotFound(error: Error): boolean {
     return /not.?found|no.?such.?key|does.?not.?exist|404/i.test(error.message)
   }

   Verified: the updated pattern matches the offending message (=> true) while still matching NoSuchKey, 404 Not Found, and no such key.

2. Code-based classification (robust, recommended follow-up). In the runtime object-store adapter, preserve the SDK error code/name (NoSuchKey, HTTP 404) on the returned error and have isNotFound() check the structured code first, falling back to the message regex for non-AWS S3-compatible stores. This avoids future drift when a provider's message wording differs (R2/B2/MinIO phrasings vary).

Suggested next steps

• Apply fix feat: update repo settings for agent #1 to isNotFound() in store.ts to unblock first-use immediately.
• Add a regression test asserting getBindingByRepo returns ok(null) when the adapter errors with "...The specified key does not exist." (and ideally table-driven cases for NoSuchKey, 404, R2/B2 phrasings).
• Follow-up: thread the SDK error code through the runtime adapter and switch isNotFound() to prefer code-based matching (fix Dependency Dashboard #2).
• Confirm whether a backport to the v0.46.x / v0.47.x lines is needed, since the report states both lines carry the same implementation.

This is a small, well-scoped, high-impact fix. Happy to open a PR with fix #1 plus the regression test if you'd like — just say the word.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/agent
Run ID	26708699333
Cache	hit
Session	ses_182ac09e8ffeY8Y4BECRU6RCp6