#26 - docs(agents): where the logs go after a rollout, and why | json returns nothing - jlxq0/caldav-mcp - Forgejo — Oddie Apps: Source forge for Oddie Apps & The Hanso Group.

jlxq0 commented

2026-08-26 14:46:32 +00:00

Owner

Documentation only, from recovering the identity enumeration after the v0.2.0 deploy. Clark ran the Loki query; both traps are recorded here because the next person to read this service's logs meets them in this order.

A rollout erases the kubectl history and --previous does not help, because ArgoCD replaces the pod rather than restarting the container, so there is no prior container to read. The v0.2.0 rollout destroyed the 58 tool-call lines that were the evidence base for the investigation that motivated the release, at the moment the release succeeded. alloy ships to Loki and holds fourteen days.

And | json returns nothing against lines that exist. This service emits nested tracing JSON, so Loki's parser produces fields_user_hash and a filter on user_hash matches nothing. An identity that never authenticated produces the identical empty set, so the parser bug and the real answer are indistinguishable. That is the third instance today of an absence meaning two things, after a 429 that names no limiter and a mutation that never applied. Use regexp, and cross-check a zero against a line visible in kubectl logs.

The recovered answer, for the record: one identity, f5a076c6a6c82848 = julian@kampong.social, 367 audit lines across five pods in fourteen days. caldav_test@kampong.social hashes to 64ce710d59fb1d01 and appears nowhere, confirming the OIDC finding from the other side.

Gates green: fmt, test (116 + 9). No code change.

Documentation only, from recovering the identity enumeration after the v0.2.0 deploy. Clark ran the Loki query; both traps are recorded here because the next person to read this service's logs meets them in this order. **A rollout erases the `kubectl` history and `--previous` does not help**, because ArgoCD replaces the pod rather than restarting the container, so there is no prior container to read. The v0.2.0 rollout destroyed the 58 tool-call lines that were the evidence base for the investigation that motivated the release, at the moment the release succeeded. `alloy` ships to Loki and holds fourteen days. **And `| json` returns nothing against lines that exist.** This service emits nested `tracing` JSON, so Loki's parser produces `fields_user_hash` and a filter on `user_hash` matches nothing. An identity that never authenticated produces the identical empty set, so the parser bug and the real answer are indistinguishable. That is the third instance today of an absence meaning two things, after a 429 that names no limiter and a mutation that never applied. Use `regexp`, and cross-check a zero against a line visible in `kubectl logs`. The recovered answer, for the record: one identity, `f5a076c6a6c82848` = `julian@kampong.social`, 367 audit lines across five pods in fourteen days. `caldav_test@kampong.social` hashes to `64ce710d59fb1d01` and appears nowhere, confirming the OIDC finding from the other side. Gates green: fmt, test (116 + 9). No code change.

jlxq0 added 1 commit

2026-08-26 14:46:32 +00:00

docs(agents): where the logs go after a rollout, and why | json returns nothing

CI / cargo (pull_request) Successful in 43s

Details

CI / docker (pull_request) Successful in 51s

Details

78627bd3b7

Two findings from recovering the identity enumeration after the v0.2.0 deploy.

A rollout replaces the pod rather than restarting the container, so kubectl
loses the history and --previous has no prior container to read. The v0.2.0
rollout erased the tool-call lines that were the evidence base for the
investigation that motivated it, at the moment it succeeded. alloy ships to
Loki and holds fourteen days.

And Loki's | json parser flattens this service's nested tracing output to
fields_user_hash, so a filter on user_hash matches nothing against lines that
exist. An identity that never authenticated produces the identical empty set,
which makes the parser bug and the real answer indistinguishable. Use regexp,
and cross-check a zero against a line visible in kubectl logs.

jlxq0 merged commit 2089525a18 into main

2026-08-26 14:48:23 +00:00

jlxq0 deleted branch docs-log-retrieval

2026-08-26 14:48:23 +00:00

jlxq0 referenced this pull request from a commit

2026-08-26 14:48:23 +00:00

Merge pull request 'docs(agents): where the logs go after a rollout, and why | json returns nothing' (#26) from docs-log-retrieval into main

Rows
Columns

docs(agents): where the logs go after a rollout, and why | json returns nothing #26