A backend worker died under load after a notifying POST (blocking calls in async handlers?) #841

New issue

Closed

opened 2026-09-26 14:38:45 +00:00 by claude-bot · 7 comments

claude-bot commented 2026-09-26 14:38:45 +00:00

Collaborator

Copy link

Seen twice during lane 7's journey runs (#733) on a loaded machine, where another stack was using about 2 GB of Docker's 7 GB. A backend worker died ("Child process died", then an nginx 502) right after a POST that notifies: a discussion reply, and a session confirm.

Uvicorn 0.52's 5-second worker health check killed a worker whose event loop had blocked. The suspicion is synchronous Celery .delay() or Redis calls made inside async request handlers on the notify path. Under load, these block the loop past the health-check window.

A related symptom: J1's keyboard project began losing an Enter while a page was still arriving, 2 of 5 runs after lane 7, where it had been 6 of 6 before. The test now waits for the heading, which may be hiding an app-side race.

To do:

• find blocking calls on async paths: notify, enqueue, and Redis publishes;
• move them off the loop, with run_in_threadpool or an async client;
• add a test or a load harness that catches a blocked loop.

Refs #733, #726.

Seen twice during lane 7's journey runs (#733) on a loaded machine, where another stack was using about 2 GB of Docker's 7 GB. A backend worker died ("Child process died", then an nginx 502) right after a POST that notifies: a discussion reply, and a session confirm. Uvicorn 0.52's 5-second worker health check killed a worker whose event loop had blocked. The suspicion is synchronous Celery `.delay()` or Redis calls made inside async request handlers on the notify path. Under load, these block the loop past the health-check window. **A related symptom:** J1's keyboard project began losing an Enter while a page was still arriving, 2 of 5 runs after lane 7, where it had been 6 of 6 before. The test now waits for the heading, which may be hiding an app-side race. **To do:** - find blocking calls on async paths: notify, `enqueue`, and Redis publishes; - move them off the loop, with `run_in_threadpool` or an async client; - add a test or a load harness that catches a blocked loop. Refs #733, #726.

claude-bot commented 2026-09-26 15:33:03 +00:00

Author

Collaborator

Copy link

Seen again (2026-09-26), in J4 phone's Notes step during lane 7's integration run. Three session-page requests all came back 502 at the same moment, after about 5.5 s. That matches a worker death. Backend memory in the next run was sampled at about 345–352 MiB of the container's 512 MiB limit, so running out of memory is also possible, alongside the 5 s health check. The final run, with nothing else on Docker, was green.

**Seen again (2026-09-26),** in J4 phone's Notes step during lane 7's integration run. Three session-page requests all came back 502 at the same moment, after about 5.5 s. That matches a worker death. Backend memory in the next run was sampled at about 345–352 MiB of the container's 512 MiB limit, so running out of memory is also possible, alongside the 5 s health check. The final run, with nothing else on Docker, was green.

claude-bot referenced this issue 2026-09-26 15:33:22 +00:00

Lane 7: Talking — discussions, Talk tabs, Needs you, and Table rules & safety pages (#733) [HOLD for owner's T-answers] #846

claude-bot referenced this issue 2026-09-26 15:45:50 +00:00

After /record/start returns 200, GET /sessions/{id} once still read "confirmed" (D116) #845

claude-bot commented 2026-09-26 15:54:27 +00:00

Author

Collaborator

Copy link

Picking this up (2026-09-26) on fix/841-blocking-loop. Evidence first:

• uvicorn's health-check mechanics;
• an inventory of blocking calls on async paths;
• a repro with a slow or paused Redis.

Then a single off-loop helper for Celery publishes and sync Redis, plus a regression guard.

Picking this up (2026-09-26) on `fix/841-blocking-loop`. Evidence first: - uvicorn's health-check mechanics; - an inventory of blocking calls on async paths; - a repro with a slow or paused Redis. Then a single off-loop helper for Celery publishes and sync Redis, plus a regression guard.

rbrooks referenced this issue from a commit 2026-09-26 16:48:46 +00:00

fix(backend): bound the Celery result backend like the broker (#841)

rbrooks referenced this issue from a commit 2026-09-26 16:48:46 +00:00

fix(backend): make every Celery publish off the event loop (#841)

claude-bot referenced this issue 2026-09-26 16:49:00 +00:00

fix(webapp): Celery publishes no longer freeze a backend worker when Redis stalls (#841) #850

claude-bot commented 2026-09-26 16:49:08 +00:00

Author

Collaborator

Copy link

Findings (2026-09-26). The fix for the real blocking is in #850; the worker kills are still unexplained.

1. A blocked loop can't trip uvicorn's health check.

• In uvicorn 0.52.4 (supervisors/multiprocess.py), the health-check pong is answered by a separate thread (always_pong), not the event loop. The parent polls each worker with a 5 s timeout and logs "Child process [pid] died" when it kills one. That same line is logged for any death.
• Two experiments under --workers 2:
  • time.sleep(12) in an async def freezes the loop but releases the GIL. It was not killed.
  • A single C call holding the GIL for more than 5 s was killed at 5.17 s, and nginx showed a 502.
• The real enqueue path with Redis paused froze a worker for 26 s with no kill, because socket waits release the GIL.
• So: sync publishes froze workers (fixed in #850), but they didn't cause the "Child process died" events.

2. The best hypothesis for the kills (medium confidence, not reproduced): memory stalls in the Docker VM.

• The ~5.5 s 502 timing matches a health-check kill, which needs the whole process unscheduled or the GIL held for more than 5 s.
• There was no kernel OOM kill: oom_kill 0 since boot.
• The VM has heavy swap and memory-pressure history:
  • about 5.5 GB swapped out;
  • 2M major faults;
  • PSI memory full at 657 s.
• A worker thrashing on page-ins while holding the GIL, e.g. during GC, fits that, and it also fits "the unloaded run was green".
• A proper repro needs VM-wide contention, which would have hit another agent's journey stack.

Follow-ups, not done:

• e2e: UVICORN_TIMEOUT_WORKER_HEALTHCHECK=15 and/or more mem_limit for the backend (it's 512m). Sample docker stats and /proc/pressure/memory during a journeys run to confirm.
• Async Redis clients (app/redis_pool.py, the ad-hoc aioredis.from_url calls) have no socket timeouts. A paused Redis hangs that request indefinitely (not the loop).
• notify() could stop enqueueing further recipients after the first broker failure. Each one still costs up to ~8 s during an outage, now off the loop.
• J1's lost Enter: a frozen worker can lengthen "page still arriving", but it can't drop a keypress. Any race is frontend-side.

Leaving this open for the kill hypothesis and the follow-ups.

**Findings (2026-09-26). The fix for the real blocking is in #850; the worker kills are still unexplained.** **1. A blocked loop can't trip uvicorn's health check.** - In uvicorn 0.52.4 (`supervisors/multiprocess.py`), the health-check pong is answered by a **separate thread** (`always_pong`), not the event loop. The parent polls each worker with a 5 s timeout and logs "Child process [pid] died" when it kills one. That same line is logged for any death. - Two experiments under `--workers 2`: - `time.sleep(12)` in an `async def` freezes the loop but releases the GIL. It was **not** killed. - A single C call holding the GIL for more than 5 s **was** killed at 5.17 s, and nginx showed a 502. - The real enqueue path with Redis paused froze a worker for 26 s with **no** kill, because socket waits release the GIL. - **So:** sync publishes froze workers (fixed in #850), but they didn't cause the "Child process died" events. **2. The best hypothesis for the kills (medium confidence, not reproduced): memory stalls in the Docker VM.** - The ~5.5 s 502 timing matches a health-check kill, which needs the whole process unscheduled or the GIL held for more than 5 s. - There was no kernel OOM kill: `oom_kill 0` since boot. - The VM has heavy swap and memory-pressure history: - about 5.5 GB swapped out; - 2M major faults; - PSI memory `full` at 657 s. - A worker thrashing on page-ins while holding the GIL, e.g. during GC, fits that, and it also fits "the unloaded run was green". - A proper repro needs VM-wide contention, which would have hit another agent's journey stack. **Follow-ups, not done:** - **e2e:** `UVICORN_TIMEOUT_WORKER_HEALTHCHECK=15` and/or more `mem_limit` for the backend (it's 512m). Sample `docker stats` and `/proc/pressure/memory` during a journeys run to confirm. - **Async Redis clients** (`app/redis_pool.py`, the ad-hoc `aioredis.from_url` calls) have no socket timeouts. A paused Redis hangs that request indefinitely (not the loop). - **`notify()`** could stop enqueueing further recipients after the first broker failure. Each one still costs up to ~8 s during an outage, now off the loop. - **J1's lost Enter:** a frozen worker can lengthen "page still arriving", but it can't drop a keypress. Any race is frontend-side. Leaving this open for the kill hypothesis and the follow-ups.

claude-bot referenced this issue from a commit 2026-09-26 17:57:17 +00:00

Merge PR #850: Celery publishes no longer freeze a backend worker when Redis stalls (#841)

claude-bot commented 2026-10-01 17:36:20 +00:00

Author

Collaborator

Copy link

Picking up two of the follow-ups (1 Oct), on fix/841-redis-timeouts:

1. Socket timeouts on the async Redis clients, from one place in app/redis_pool.py, with every ad-hoc from_url site converted. Blocking reads (pub/sub, stream consumers) keep no read timeout or a longer one, and a timeout takes the same path a Redis outage already does at each site.
2. notify() stops enqueueing after the first broker failure in one call, while still writing every in-app row and without letting one bad payload stop the others.

Not doing, because they are the owner's call: the backend's mem_limit (512m in docker-compose.yml) and uvicorn's worker health-check timeout. The worker kills have not been seen since the CI runner's capacity was raised on 29 Sep; today's eight full CI runs were all green. If they stay away, the remaining hypothesis (memory stalls in a contended Docker VM) is an environment matter, and this issue can close when these two land.

Picking up two of the follow-ups (1 Oct), on `fix/841-redis-timeouts`: 1. **Socket timeouts on the async Redis clients**, from one place in `app/redis_pool.py`, with every ad-hoc `from_url` site converted. Blocking reads (pub/sub, stream consumers) keep no read timeout or a longer one, and a timeout takes the same path a Redis outage already does at each site. 2. **`notify()` stops enqueueing after the first broker failure** in one call, while still writing every in-app row and without letting one bad payload stop the others. Not doing, because they are the owner's call: the backend's `mem_limit` (512m in `docker-compose.yml`) and uvicorn's worker health-check timeout. The worker kills have not been seen since the CI runner's capacity was raised on 29 Sep; today's eight full CI runs were all green. If they stay away, the remaining hypothesis (memory stalls in a contended Docker VM) is an environment matter, and this issue can close when these two land.

claude-bot commented 2026-10-01 17:39:35 +00:00

Author

Collaborator

Copy link

Correction to my last comment: "eight full CI runs, all green" overstated it. Today's count, checked: four PR runs green (#986, #987, #989, #992) and two of main's push runs green (after #987 and #989); main's run after #986 was cancelled when the next push superseded it, and one is running now. No worker deaths in any of them. The scheduled Dependency Audit did fail this morning, for unrelated reasons (#995).

Correction to my last comment: "eight full CI runs, all green" overstated it. Today's count, checked: four PR runs green (#986, #987, #989, #992) and two of main's push runs green (after #987 and #989); main's run after #986 was cancelled when the next push superseded it, and one is running now. No worker deaths in any of them. The scheduled Dependency Audit did fail this morning, for unrelated reasons (#995).

rbrooks referenced this issue from a commit 2026-10-01 17:47:21 +00:00

Redis calls time out instead of hanging a request; notify stops at a dead broker (#841)

rbrooks referenced this issue from a commit 2026-10-01 17:48:45 +00:00

Redis replies get ten seconds, not two: an event-loop stall must not fail a session lookup (#841)

claude-bot referenced this issue 2026-10-01 19:23:24 +00:00

Redis calls time out instead of hanging a request; notify stops at a dead broker (#841) #1002

claude-bot referenced this issue 2026-10-01 20:16:35 +00:00

Dev deploy, 1 Oct: lane 11, the R3 fixes and today's issue fixes #1004

claude-bot referenced this issue from a commit 2026-10-01 20:16:58 +00:00

Merge PR #1002: Redis calls time out instead of hanging a request; notify stops at a dead broker (#841)

claude-bot commented 2026-10-01 20:23:20 +00:00

Author

Collaborator

Copy link

The two code follow-ups are merged in #1002 (1 Oct, main c95fe032):

• Redis clients have timeouts, held in one place (app/redis_pool.py): 2 s to connect, 10 s for a reply. Ten and not two because on an async client the wait is measured on the event loop, so a loop stall would otherwise fail session lookups. The live recording-status stream, the one blocking reader, keeps no read timeout. A guard test fails if a module builds a Redis client without them.
• notify() stops enqueueing after the first broker connectivity failure in a call, still writes every in-app row, and doesn't let one bad payload stop the others.

What is left is the owner's: whether to raise the backend's mem_limit (512m in docker-compose.yml) or uvicorn's worker health-check timeout. The kills this issue was opened for haven't been seen since the CI runner's capacity was raised on 29 Sep. Leaving this open for that call.

The two code follow-ups are merged in #1002 (1 Oct, main c95fe032): - Redis clients have timeouts, held in one place (`app/redis_pool.py`): 2 s to connect, 10 s for a reply. Ten and not two because on an async client the wait is measured on the event loop, so a loop stall would otherwise fail session lookups. The live recording-status stream, the one blocking reader, keeps no read timeout. A guard test fails if a module builds a Redis client without them. - `notify()` stops enqueueing after the first broker connectivity failure in a call, still writes every in-app row, and doesn't let one bad payload stop the others. **What is left is the owner's:** whether to raise the backend's `mem_limit` (512m in `docker-compose.yml`) or uvicorn's worker health-check timeout. The kills this issue was opened for haven't been seen since the CI runner's capacity was raised on 29 Sep. Leaving this open for that call.

claude-bot referenced this issue 2026-10-01 23:39:04 +00:00

After /record/start returns 200, GET /sessions/{id} once still read "confirmed" (D116) #845

rbrooks referenced this issue from a commit 2026-10-02 03:04:22 +00:00

Cut spans twenty-five to a process, not fifty: the worker's memory (#684)

claude-bot referenced this issue 2026-10-02 03:22:53 +00:00

Transcription cuts a speaker's phrases twenty-five at a time, not one ffmpeg process each (#684) #1027

claude-bot referenced this issue 2026-10-02 20:58:20 +00:00

[CI][Performance] The synthetic session harness spends ~17 minutes spawning ffmpeg one span at a time #684

claude-bot referenced this issue 2026-10-03 23:29:21 +00:00

[Security] Campaign import reads data.json with no cap on its decompressed size #1054

claude-bot referenced this issue 2026-10-04 08:50:04 +00:00

[Security] An uploaded image can exhaust the backend's memory: the validator decodes it with no pixel bound #1074

claude-bot commented 2026-10-05 05:45:41 +00:00

Author

Collaborator

Copy link

Closing, by the owner's answer to Q160 (O35), 2026-10-05: "Close it: it has not come back."

• The code follow-ups were merged in #1002.
• The kills have not been seen since the runner's capacity was raised.
• The backend's memory is now handled where it is actually tight:
  • the import moves to the worker (#1054, the owner's answer to Q153);
  • pictures are bounded before they are opened (#1074, #1087).

Reopen if a backend worker dies under load again.

**Closing, by the owner's answer to Q160 (O35), 2026-10-05: "Close it: it has not come back."** - The code follow-ups were merged in #1002. - The kills have not been seen since the runner's capacity was raised. - The backend's memory is now handled where it is actually tight: - the import moves to the worker (#1054, the owner's answer to Q153); - pictures are bounded before they are opened (#1074, #1087). Reopen if a backend worker dies under load again.

claude-bot closed this issue 2026-10-05 05:45:42 +00:00

claude-bot referenced this issue from a pull request that will close it, 2026-10-05 05:57:33 +00:00

Decisions D279 to D287, the owner's answers of 5 October (Q151 to Q159), with two of them built (#677, #367) #1097

rbrooks referenced this issue from a commit 2026-11-06 15:59:27 +00:00

feat(webapp): digest weekday choice and one-click stop; fix the off-loop check (#11)

claude-bot referenced this issue 2026-11-06 15:59:39 +00:00

The weekly email digest (#11) #1358

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

feat/1328-fill-it-in

feat/1328-fill-frontend

feat/1328-fill-backend

feat/9-foundry-push

fix/9-foundry-live

feat/9-foundry-push-frontend

renovate/celery-5.x

feat/5-foundry-connect

feat/9-foundry-push-backend

feat/9-foundry-push-module

feat/5-foundry-frontend

feat/5-foundry-backend

feat/5-foundry-module

release/v4.8.0-rc1

docs/d341-convert-draft

feat/958-update-to-version

feat/958-convert-sheet

feat/958-pathbuilder-import-frontend

fix/1360-heading-order

feat/958-pathbuilder-import-backend

feat/11-weekly-digest

feat/1341-auto-update

docs/d332-superseded

chore/1345-names-cleanup

feat/1342-mentioned-pages

feat/1328-recipes

fix/1346-pgdg-key

perf/1247-shared-recording-stream

chore/132-gitleaks-allowlist

release/v4.7.1

spike/foundry-module

release/v4.7.1-rc1

docs/decisions-d332-d337

fix/bot-certifi

chore/release-4.7.0

chore/release-4.7.0-rc4

chore/deps-4.7.0

chore/release-4.7.0-rc3

fix/1280-quote-must-say-it

fix/1257-names-row-squeeze

chore/release-4.7.0-rc2

fix/1245-pg-upgrade-count

chore/release-4.7.0-rc1

feat/1257-names-in-prep

feat/1257-be

feat/1257-fe

feat/1257-rating-fixes

design/1328-fill-it-in

feat/1257-name-splits

fix/1326-redis-503

feat/1280-fact-suggestions

feat/1280-be

feat/1280-fe

design/1280-fact-suggestions

feat/1279-infobox

feat/1279-be

feat/1279-fe

feat/1321-shelf-copies

design/1279-infobox

feat/1243-table-find

feat/1257-who-rated

feat/1243-prep-drawer

feat/1243-sheet-pickers

design/1243-browse-in-place

feat/1315-hotwords-default

feat/1242-system-filters

feat/1257-more-name-styles

feat/506-leg3-hotwords

design/1242-system-filters

fix/1302-packs-polish

feat/1241-rules-library

design/1241-rules-library

feat/1245-postgres-18

integ/4.6.2

fix/1263-map-ui-2

fix/1263-map-server

fix/1263-map-ui-1

fix/1261-editor-link-menu

fix/1229-axe-4.14-name-mismatch

renovate/axllent-mailpit-1.x

renovate/eslint-monorepo

renovate/authlib-1.x

chore/release-4.6.0

chore/release-4.6.0-rc2

fix/460-rc2-screens

fix/460-rc2-server

fix/release-prerelease-exit

chore/release-4.6.0-rc1

feat/125-campaign-templates

feat/126-calendar

feat/1181-pictures-and-files

feat/1190-event-people

integ/4.6.0

feat/1191-line-of-the-night

feat/1200-starter-packs

chore/bot-multidict-and-playwright-group

fix/1202-this-week-answered-count

fix/122-124-leftovers

fix/1178-get-routes-that-write

fix/1203-journeys-check-names

design/125-campaign-templates

feat/126-calendar-engine

design/126-in-world-calendar

fix/1189-cited-stamp-in-range

fix/1189-v4-looser-check

fix/1189-richer-beats

fix/1113-export-bind-lists

fix/1154-release-notes-by-file

chore/release-4.5.0

chore/release-4.5.0-rc12

fix/1135-wiki-markup-as-text

fix/demo-usage-cost-in-window

chore/release-4.5.0-rc11

fix/1121-sheet-consistency

fix/1121-sheet-5e-terms-and-card-hp

copy/1122-busiest-pages

fix/1121-relevant-choices

fix/1121-wiki-create-npc-save-sheet-links

fix/1029-menu-stays-on-screen

docs/prototype-transcript-bin-wording

fix/1023-editor-save-row-back-scroll

fix/1020-search-exact-first

fix/1020-table-prep

fix/1020-shell-wordmark-footer-bell

fix/1020-wiki-article-party

fix/872-admin-kept-until-phone-tables

feat/l13-milestone-level-waiting

fix/1000-1001-bell-older-setup-context

fix/999-pronouns-in-prompts

fix/l19-other-class-feats

fix/1010-transcript-window-ordinary-confirm

docs/d254-d269-decisions

fix/702-member-search

fix/680-transcript-bin

fix/993-unidentified-prompts

fix/841-redis-timeouts

fix/990-binned-not-exported

fix/830-export-prep-shelf

fix/deps-audit-2026-10-01

fix/877-title-reads

fix/798-audio-received-at

build/lane11-17-j7

build/lane11-16-levelup

build/lane11-14-seams

build/lane11-14-seed

build/lane11-15-start

build/lane11-13-old-block-out

fix/980-review-r3

build/lane11-12-block

build/lane11-8-packs

fix/demo-seed-canonical-names

build/lane11-11-hot-half

docs/l11-decisions

build/lane11-7-convert

build/lane11-10-editing

fix/npm-audit-brace-expansion

build/lane11-9-sheet-page

fix/bot-pyjwt

build/lane11-6-content

fix/lane11-rank-names

build/lane11-2b-language

build/lane11-4-js-evaluator

build/lane11-3-server

build/lane11-5a-pf2e

build/lane11-5b-5e

feat/design-admin

build/lane11-2-evaluator

build/lane11-1-sheet-pieces

build/lane11-0-drawing

fix/943-quest-objectives-fk

fix/prepsheet-shelf-flake

fix/945-leftovers

build/demo-gm-copy

fix/901-email-landings

build/lane10-8-journeys

build/demo-seed-lanes-8-10

fix/887-gm-own-confirmation

build/lane9-5-j1-admin

fix/918-audience-click

fix/useasync-overtaken

ci/939-critical-path

test/937-backend-suite-speed

chore/claude-orchestration

fix/924-xp-gm-only

fix/session-stale-poll

docs/decisions-d239-d242

fix/930-pypdf

build/lane8-journeys

build/925-quest-editor

fix/894-private-page-pictures

build/lane8-p4-drafts

build/lane8-p7-map

build/lane8-p6-handouts-rules

fix/wiki-fixture-names

build/lane10-d227-test-usage

fix/rsvp-horizon-test-tuesday

fix/media-volume-owner

build/lane8-p3-editor

fix/912-unidentified-rename

build/lane8-p5-party-quests

build/lane8-handout-takeback

build/lane10-pickers

build/lane8-p2-article

build/lane8-6-map

build/lane10-7b-email-pages

build/lane8-5-handouts

build/lane10-7a-test-the-bot-pages

build/lane8-p1-pages

build/lane8-4-quests

build/lane8-2b-feeds

build/lane8-3-parties

build/lane8-2a-links

build/lane10-5-commands

build/lane9-6-seed

build/lane10-4b-reactions

build/lane9-4d-pages

build/lane9-4c-pages

build/lane10-4a-posts

build/lane10-3-email

fix/891-web-fonts

build/lane9-4b-pages

build/lane10-6-test-the-bot

build/lane10-2-notify-out

build/lane8-1-wiki-text

build/lane9-4a-frame

design/lane10-drawings

fix/j6-budget

fix/j5-phone-flake

fix/869-test-leaks

fix/843-record-start-followups

build/lane7-all

build/lane6-all

build/lane9-b2-server

chore/changelog-fragments

docs/decisions-d218

build/lane9-a-owner-overview

fix/rule-card-level-label

fix/834-retention-semantics

fix/o3c-record-without-announcement

docs/decisions-d179

docs/decisions-d131-d170

fix/851-commit-before-response

build/lane6-j3-seed

build/lane9-b1-d67-identity

fix/841-blocking-loop

build/lane9-c-backups-audit

fix/vote-race-and-start-commit

fix/recording-announcement

fix/proposal-read-leak

fix/last-admin-guard

build/lane6-p4c-planning

build/lane6-p4b-margin

build/lane6-p4a-sheet

build/lane5-j4-seed

build/lane6-base

build/lane7-pages-talk

build/lane5-pages

build/lane7-pages-safety

build/lane7-p3-safety

build/lane7-p2-notify

build/lane6-p3-planning

build/lane6-p2-history

build/lane6-p1b-items

build/lane7-p1-threads

build/lane5-p6-faces

build/lane6-p1a-sheet

build/lane5-p5-find

build/lane5-p4a-board

build/lane5-p4b-scenes

build/lane5-p3-live

build/lane5-base

build/lane5-p2-cards

docs/lane5-decisions

build/review-r2-wide

fix/review-r1

build/lane5-p1-scenes

build/demo-seed

build/lane4-journeys-j5

build/lane4-page-review-b

build/lane4-page-review-a

build/lane4-page-read

build/lane4-journeys

build/lane4-page-sess2

build/lane4-page-sess1

build/lane4-notes

build/lane4-discord-on-approval

build/lane4-scheduling

build/lane4-versions

build/760-session-number

build/lane4-decisions

build/797-erase-no-regenerate

build/test-race-audit

build/lane3-completions

build/794-dark-only

build/796-titles-scroll

build/791-retention-anchor

build/a11y-sweep

build/shell-followups

build/retention-preview

build/753-backup-readback

docs/d91-d93

build/lane3-j1

build/ci-harness-paths-selftest

fix/useauth-test-race

build/ci-harness-paths

build/777-ai-settings-read

build/lane3-settings-c

build/lane3-settings-b

build/lane3-j6

build/lane3-sessionform

build/lane3-settings-a

build/lane3-members

build/lane3-thisweek

build/lane3-story

chore/87-align-python-3.12

v4.8.0-rc1

v4.7.1

v4.7.1-rc1

v4.7.0

v4.7.0-rc4

v4.7.0-rc3

v4.7.0-rc2

v4.7.0-rc1

v4.6.2

v4.6.2-rc4

v4.6.2-rc3

v4.6.2-rc2

v4.6.2-rc1

v4.6.1

v4.6.1-rc1

v4.6.0

v4.6.0-rc2

v4.6.0-rc1

v4.5.3

v4.5.3-rc1

v4.5.2

v4.5.2-rc1

v4.5.1

v4.5.1-rc2

v4.5.1-rc1

v4.5.0

v4.5.0-rc12

v4.5.0-rc11

v4.5.0-rc10

v4.5.0-rc9

v4.5.0-rc8

v4.5.0-rc7

v4.5.0-rc6

v4.5.0-rc5

v4.5.0-rc4

v4.5.0-rc3

v4.5.0-rc2

v4.5.0-rc1

v4.4.1

v4.4.0

v4.3.0

v4.2.3

v4.2.2

v4.2.1

v4.2.0

v4.1.2

v4.1.1

v4.1.0

v4.0.1

v4.0.0

v3.11.4

v3.11.3

v3.11.2

v3.11.1

v3.11.0

v3.10.0

v3.9.1

v3.9.0

v3.8.0

v3.7.0

v3.6.1

v3.6.0

v3.5.0

v3.4.1

v3.4.0

v3.3.0

v3.2.0

v3.1.0

v3.0.0

v2.1.0

v2.0.0

v1.1.0

v1.0.0

v0.12.0

v0.11.0

v0.10.0

v0.9.1

v0.3.3

v0.9.0

v0.8.0

v0.3.2

v0.3.1

v0.3.0

v0.7.0

v0.6.0

v0.5.0

v0.4.0

v0.2.1

v0.2.0

v0.1.1

v0.1.0

Labels

Clear labels   

backend

Issue related to the backend

  

bot

Issue related to the bot

  

bug

Something is not working

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

frontend

Issue related to the frontend

  

help wanted

Need some help

  

invalid

Something is wrong

  

question

More information is needed

  

recording

Issue related to the recording system

  

security

Security hardening / vulnerability work

  

wontfix

This won't be fixed

No labels

backend

bot

bug

duplicate

enhancement

frontend

help wanted

invalid

question

recording

security

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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

rbrooks/Quest-Board#841

No description provided.