guettli/sharedinbox
1
0
Fork 0
Code Issues 21 Pull Requests 6 Actions Packages Projects Releases Wiki Activity

Firebase Tests failed — find root cause and fix #549

New Issue
Closed
opened 2026-06-09 03:05:43 +00:00 by forgejo-actions · 1 comment
forgejo-actions commented 2026-06-09 03:05:43 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Firebase instrumented tests failed in the daily run.

Failed run: https://codeberg.org/guettli/sharedinbox/actions/runs/4601135

Steps to resolve

  1. Find the root cause: Check the test run logs linked above and identify which test(s) failed and why.
  2. Fix if possible: If the failure is caused by a code bug, create a fix. If it is a flaky or infrastructure issue, document the findings.
  3. Close this issue once the root cause is resolved and the tests pass.

⚠️ agentloop skipped this issue.

Its author forgejo-actions is not in this loop's configured usernames allowlist, so agentloop will not start an agent on it even though it carries a managed input label. Add forgejo-actions to the loop's usernames (or have an allowlisted user re-file the issue) to let it run.

Agentloop runs

# Started (UTC) Ended (UTC) Status Tokens in Tokens out
1 2026-06-10 09:54:44 2026-06-10 10:09:46 success 99 38 206
Firebase instrumented tests failed in the daily run. **Failed run:** https://codeberg.org/guettli/sharedinbox/actions/runs/4601135 ## Steps to resolve 1. **Find the root cause**: Check the test run logs linked above and identify which test(s) failed and why. 2. **Fix if possible**: If the failure is caused by a code bug, create a fix. If it is a flaky or infrastructure issue, document the findings. 3. Close this issue once the root cause is resolved and the tests pass. <!-- agentloop-skipped --> ⚠️ **agentloop skipped this issue.** Its author `forgejo-actions` is not in this loop's configured `usernames` allowlist, so agentloop will not start an agent on it even though it carries a managed input label. Add `forgejo-actions` to the loop's `usernames` (or have an allowlisted user re-file the issue) to let it run. <!-- /agentloop-skipped --> --- --- <!-- agentloop-summary --> **Agentloop runs** | # | Started (UTC) | Ended (UTC) | Status | Tokens in | Tokens out | |---|---------------------|---------------------|---------|-----------|------------| | 1 | 2026-06-10 09:54:44 | 2026-06-10 10:09:46 | success | 99 | 38 206 |
guettlibot commented 2026-06-10 10:09:46 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

PR created: https://codeberg.org/guettli/sharedinbox/pulls/554---

Summary for the issue

I traced the failing Firebase Test Lab run (actions/runs/2284) and found the failure in the Run Android Tests on Firebase Test Lab step:

> Timeout waiting to lock journal cache (/home/ci/.gradle/caches/journal-1). It is currently in use by another process.
  Owner PID: 88
  Our PID: 53

Root cause — in ci/main.go::BuildAndroidDebugApks, two Gradle invocations share the persistent Dagger gradle-cache mount at /home/ci/.gradle:

  1. flutter build apk --debug --no-pub — spawns a Gradle daemon (PID 88).
  2. ./gradlew --no-daemon app:assembleAndroidTest — runs in the next Dagger layer.

When step 1's WithExec ends, Dagger snapshots the filesystem and tears the container down, force-killing the daemon. The daemon's lock file at …/journal-1/journal-1.lock is left behind on the persistent cache volume. In step 2's fresh container, that PID is gone, but Gradle still respects the stale lock and times out after 60 s. The pre-existing --no-daemon on step 2 only prevented stale daemon-registry reuse, not stale lock files.

Fix — chain ./gradlew --stop into the first WithExec, so the daemon shuts down gracefully and releases its locks before Dagger snapshots the layer.

PR: https://codeberg.org/guettli/sharedinbox/pulls/554 (Closes #549)

agentloop · agent: claude

PR created: https://codeberg.org/guettli/sharedinbox/pulls/554--- ## Summary for the issue I traced the failing Firebase Test Lab run (`actions/runs/2284`) and found the failure in the `Run Android Tests on Firebase Test Lab` step: ``` > Timeout waiting to lock journal cache (/home/ci/.gradle/caches/journal-1). It is currently in use by another process. Owner PID: 88 Our PID: 53 ``` **Root cause** — in `ci/main.go::BuildAndroidDebugApks`, two Gradle invocations share the persistent Dagger `gradle-cache` mount at `/home/ci/.gradle`: 1. `flutter build apk --debug --no-pub` — spawns a Gradle daemon (PID 88). 2. `./gradlew --no-daemon app:assembleAndroidTest` — runs in the next Dagger layer. When step 1's `WithExec` ends, Dagger snapshots the filesystem and tears the container down, force-killing the daemon. The daemon's lock file at `…/journal-1/journal-1.lock` is left behind on the persistent cache volume. In step 2's fresh container, that PID is gone, but Gradle still respects the stale lock and times out after 60 s. The pre-existing `--no-daemon` on step 2 only prevented stale daemon-registry reuse, not stale lock files. **Fix** — chain `./gradlew --stop` into the first `WithExec`, so the daemon shuts down gracefully and releases its locks **before** Dagger snapshots the layer. PR: https://codeberg.org/guettli/sharedinbox/pulls/554 (Closes #549) <sub>agentloop · agent: claude</sub>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
NeedSupervisor
Issue escalated to a human supervisor; agentloop will skip it until cleared.
 State/InProgress
State/Later
State/Planned
automerge
Eligible for automatic merge by CI
 ci-failure
Issue opened by agentloop to track a failing CI workflow; used for deduplication.
 do-not-merge
Plan PR — review only, do not merge.
 loop/code
Add to run the built-in "code" prompt; override at prompts/code.md.
 loop/code-ci-pending
Prompt "code" finished; waiting for the PR's CI to pass before advancing.
 loop/code-done
Prompt "code" finished successfully.
 loop/code-in-process
Agent for the "code" prompt is currently running on this issue.
 loop/merge
Managed by agentloop
 loop/merge-done
Managed by agentloop
 loop/merge-in-process
Managed by agentloop
 loop/plan
Add to run the built-in "plan" prompt; override at prompts/plan.md.
 loop/plan-done
Prompt "plan" finished successfully.
 loop/plan-in-process
Agent for the "plan" prompt is currently running on this issue.
No labels automerge loop/code-done
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
guettlibot guettli
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#549