Repository navigation
Description
Is there an existing issue for this?
- I searched open issues for Coil / no-store / false positive and found no matching report.
Which actions are affected?
Pull Request
Which platforms are affected?
Linux (review producer); macOS (verified application transport tests). The defect described is review reasoning/context, not an OS-specific header implementation.
Description
Bugbot reports that a private image loader cannot send Cache-Control and that its newly added runtime assertion fails, overlooking header construction performed by the actual pinned dependency. The real Coil fetch/decode/transport test passes at the analyzed commit, and Coil's primary source explains why.
Consumer: vypdev/vaultstadio#126, analyzed head 3d095f14b326ed6dc1a2ad6cecd361e4ccdb48e3, review 5695942277, finding 4410993713, fingerprint fp-e3431163, semantic key sf-743821a5, medium severity / 82% confidence. Contributor evidence reply.
Expected: inspect the dependency's policy-to-request transformation, or express uncertainty and request runtime evidence. Do not assert that an existing test fails when an unexamined library layer can provide the header.
Actual: the review examines the factory and Ktor plugin, infers the header is absent because neither sets it explicitly, and claims the transport assertion fails. This is contradicted by actual test execution and dependency source. The second review finding (UTF-8 truncation) is valid and is being repaired separately; this report does not dismiss it.
Reproducing the issue
- Inspect PrivateImageLoader: the real
KtorNetworkFetcherFactory(client)and disabled disk/memory policies are installed. - Inspect the actual fetch/decode test. Its MockEngine inspects the outgoing request, does not fabricate request headers, and serves a valid PNG. Two authenticated sessions and one tokenless rejection each traverse the actual Coil pipeline; the no-store assertion passes on all three requests. A second case rejects a foreign image without forwarding account bearer data.
- The pinned library is Coil 3.6.3, declared in the consumer version catalog. NetworkFetcher.newRequest in that release maps enabled network reads plus disabled disk reads/writes to
Cache-Control: no-cache, no-storebefore the Ktor adapter receives the request. No application-level header mutation is needed. - Run the desktop test with Java 17 and the repository's Gradle wrapper, e.g. from frontend:
./gradlew --init-script ../scripts/verification/model.gradle :composeApp:desktopTest --tests '*PrivateImageLoaderTest'. - Compare the passing runtime test with the linked finding's claimed failing assertion. No source modification, weakened policy or cache/security bypass is needed to explain the result.
copilot Version
@v3, package version 3.10.6 verified from the action repository package.json at the exact action revision resolved by run 40854037117. Consumer workflow references remain major tags, not commit pins.
Relevant Log Output
The clean consumer implementation checkpoint (35ce407, identical production/test source to analyzed 3d095f1, which adds evidence only) passes 3,397 backend + 1,729 desktop + 1,636 Wasm product executions, zero failures/errors/skips. The original source-bound XML, class files, execution data and coverage receipts are retained; full archive SHA-256 6b11659b31d639708d80de3f0f0d181fdd8c180b545a55e433fe7e9bb3ce0ef7. The two actual PrivateImageLoaderTest cases are included, rather than a locally simulated header check.
A fresh focused run also passes after tightening the header assertion to exact equality: 27 JVM and 56 actual Wasm executions, all failures/errors/skips zero. Original XML/input archive SHA-256 8ad90a77383e0386e9b964dc234352231b487cb7c9c9cbf7fa30692766e06f87. This tightening and an explanatory maintenance comment do not introduce the header; the dependency already supplied it.
Additional context and comments
Suggested improvement: include policy-driven dependency adapters in review context when a finding depends on their side effects. Add a reviewer regression fixture in which a cache-policy enum causes the pinned network library to add a header and an actual pipeline test asserts it. Distinguish an unexecuted prediction from an observed test failure, and allow cited dependency behavior plus source-bound execution evidence to reconcile the finding without requiring redundant production mutations.
No consumer Copilot configuration/catalog/workflow/protection changes are proposed. No credentials, raw capability URLs, private runtime logs or user data are included. This is separate from the evidence-shape branch-sync compatibility report #779.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
[-]Bugbot flags a missing Coil no-store header despite passing real transport tests[/-][+]🐛 - Bugbot flags a missing Coil no store header despite passing real transport tests[/+]vypbot commentedon Oct 29, 2026
Hi! I’m @vypbot, the Copilot assistant for this repository.
I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.
Try
/copilot helpto see the available commands, or mention @vypbot with your question.[-]🐛 - Bugbot flags a missing Coil no store header despite passing real transport tests[/-][+]🐛🧑💻 - Bugbot flags a missing Coil no store header despite passing real transport tests[/+]vypbot commentedon Oct 30, 2026
Implementation plan
Acceptance: A reviewer regression test passes for a policy-driven header supplied by the pinned dependency, and the review guidance requires verifying dependency behavior or qualifying the claim when runtime evidence is unavailable.
Need something else? Mention the bot with a question or use
/copilot help.bugfix-784-bugbot-flags-a-missing-coil-no-store-header-despite-passin…
Merge pull request #800 from vypdev/bugfix/784-bugbot-flags-a-missing…
vypbot commentedon Oct 30, 2026
Issue closed: synchronization recommendation retired
No branch synchronization is required for this closed issue.
The previous recommendation is historical. Issue closure does not certify that the branches are synchronized.