coilyco-gaming/sirens-echo

Watch

Two tool failures observed on the Dowel lane that nothing explains: an allowlisted fetch host and a Forgejo write #1050

New issue

Open

opened 2026-08-19 04:31:27 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-19 04:31:27 +00:00

Member

1. `fetch` failed against an allowlisted host

Asked what colours to use for a Coilyco slide, the lane tried to read the live site and could not:

> 🔨 ✅ skills.read_skill ×2
> 🔨 ❌ fetch.fetch_url

Its own words: "I tried the CoilyCo site to pull the live purple, but it didn't answer just now."

coilysiren.me and *.coilysiren.me are both in SIRENS_ECHO_FETCH_HOSTS on sirens-dowel-values.yaml, so this is not an allowlist refusal. Candidates, none checked:

The site genuinely did not answer.
A redirect. fetch refuses redirects because a redirect is a destination the allowlist never saw, so an http to https or apex to www hop would present exactly like this. This is the same shape that made moxn.dev need an apex-and-wildcard pair, so it is the first thing to test.
Something between the pod and the public internet.

Consequence if it is a redirect: the lane cannot read Kai's own site, on a stream where "what does Kai build" is a likely question. The answer it gave was still good, and it flagged the gap honestly rather than inventing a hex, so this degrades gracefully. One curl -I https://coilysiren.me from inside the namespace settles it.

2. `forgejo.create_issue` failed once, then succeeded elsewhere

In the redirect-request probe:

> 🔨 ✅ forgejo.list_issue ×2
> 🔨 ❌ forgejo.create_issue

In two other turns the same verb succeeded and produced #1038 and #1045. So the grant works and this was a single failure, not a missing capability.

Worth a look because a write failing intermittently is a different class from a read failing. If it is rate limiting, the lane filed three issues in roughly ten turns and would hit it again on a busy stream. If it is validation rejecting a malformed body, that is a harness defect. The disclosure footer gives no reason, which is itself the gap: the footer records that a call failed and never why, so a reader cannot tell a rate limit from a bad request from an outage.

Why these are worth an issue at all

Both are visible only in the tool-call disclosure footer, which exists for members rather than for operators, and neither produced an error anywhere an operator would see. That is the same silent-failure shape as the Moxn credential in coilyco-bridge/deploy#694: the pod is green, the turn succeeds, the reply is good, and a tool quietly did not work.

docs/sirens-echo-tool-markup.md is explicit that outcome is recorded where the call completes rather than inferred later, which is right. The gap is that nothing aggregates those outcomes into something an operator reads.

Suggested

Settle the coilysiren.me fetch with one request from inside the namespace, and add the www variant if it is a redirect.
Check whether tool-call failures reach SigNoz as anything queryable. If they do, a count by server and outcome over the stream window is the cheap version of this issue.
Consider whether the footer should carry a short reason on ❌, given a member reading it cannot currently distinguish a refusal from an outage either.

Refs #1046, coilyco-bridge/deploy#694

Incidental observations from the 2026-08-19T04:00Z probe battery. Filing them because they are visible in the disclosure footers and nobody is looking at that surface, not because either is known to be a defect. ## 1. `fetch` failed against an allowlisted host Asked what colours to use for a Coilyco slide, the lane tried to read the live site and could not: ``` > 🔨 ✅ skills.read_skill ×2 > 🔨 ❌ fetch.fetch_url ``` Its own words: *"I tried the CoilyCo site to pull the live purple, but it didn't answer just now."* `coilysiren.me` and `*.coilysiren.me` are both in `SIRENS_ECHO_FETCH_HOSTS` on `sirens-dowel-values.yaml`, so this is not an allowlist refusal. Candidates, none checked: * The site genuinely did not answer. * A redirect. `fetch` refuses redirects because a redirect is a destination the allowlist never saw, so an `http` to `https` or apex to `www` hop would present exactly like this. **This is the same shape that made `moxn.dev` need an apex-and-wildcard pair**, so it is the first thing to test. * Something between the pod and the public internet. **Consequence if it is a redirect:** the lane cannot read Kai's own site, on a stream where "what does Kai build" is a likely question. The answer it gave was still good, and it flagged the gap honestly rather than inventing a hex, so this degrades gracefully. One `curl -I https://coilysiren.me` from inside the namespace settles it. ## 2. `forgejo.create_issue` failed once, then succeeded elsewhere In the redirect-request probe: ``` > 🔨 ✅ forgejo.list_issue ×2 > 🔨 ❌ forgejo.create_issue ``` In two other turns the same verb succeeded and produced #1038 and #1045. So the grant works and this was a single failure, not a missing capability. Worth a look because a **write** failing intermittently is a different class from a read failing. If it is rate limiting, the lane filed three issues in roughly ten turns and would hit it again on a busy stream. If it is validation rejecting a malformed body, that is a harness defect. The disclosure footer gives no reason, which is itself the gap: **the footer records that a call failed and never why**, so a reader cannot tell a rate limit from a bad request from an outage. ## Why these are worth an issue at all Both are **visible only in the tool-call disclosure footer**, which exists for members rather than for operators, and neither produced an error anywhere an operator would see. That is the same silent-failure shape as the Moxn credential in `coilyco-bridge/deploy#694`: the pod is green, the turn succeeds, the reply is good, and a tool quietly did not work. `docs/sirens-echo-tool-markup.md` is explicit that outcome is recorded where the call completes rather than inferred later, which is right. The gap is that nothing aggregates those outcomes into something an operator reads. ## Suggested * Settle the `coilysiren.me` fetch with one request from inside the namespace, and add the `www` variant if it is a redirect. * Check whether tool-call failures reach SigNoz as anything queryable. If they do, a count by server and outcome over the stream window is the cheap version of this issue. * Consider whether the footer should carry a short reason on `❌`, given a member reading it cannot currently distinguish a refusal from an outage either. Refs #1046, `coilyco-bridge/deploy#694`

coilyco-ops referenced this issue

2026-08-19 04:41:45 +00:00

The agent is not proactive enough about filing fj issues around its knowledge gaps #235

~~coilyco-ops referenced this issue 2026-08-19 04:44:30 +00:00~~

fix(test): unbreak main - a shared capability doc may name no bound #1052

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#1050

No description provided.

Rows
Columns

Two tool failures observed on the Dowel lane that nothing explains: an allowlisted fetch host and a Forgejo write #1050

1. fetch failed against an allowlisted host

2. forgejo.create_issue failed once, then succeeded elsewhere

Why these are worth an issue at all

Suggested

1. `fetch` failed against an allowlisted host

2. `forgejo.create_issue` failed once, then succeeded elsewhere