docs(api): daily audit 2026-09-29 — RUM remote-config error-session switches, channel filter UTF-8 note

[flashduty]

api-review daily audit — 2026-09-29

--mode generate --scope all --auto. Registry baseline: fc-pgy/logic/api/api_test.go @ a127bd54 — the file is unchanged since bb995eff (2026-09-26), i.e. no row was added or removed since the 2026-09-28 run. Docs base: b1518a5.

Operations changed

Module	Added	Updated	Removed
rum	0	1 schema (reachable from 5 operations)	0
on-call	0	1 schema (1 operation)	0
monitors / safari / platform	0	0	0

No path was added or removed, so docs.json and {en,zh}/openapi/api-catalog.mdx are deliberately untouched (the reconcile step only applies when the operation set changes).

1. rum — RemoteConfigValues gains two optional switches (schema update)

fc-rum types/remote_config.go gained SessionOnError and SessionReplayOnError (both *bool, json:"…,omitempty"), merged to main in 46ca410 / bda5eb0 on 2026-09-28. Per the Go doc comments: sessionOnError keeps the sessions the session sample rate did not draw when they report an error (a session that never errors is never stored), and it only affects what that rate missed, so it does nothing alongside a rate of 100; sessionReplayOnError is the same switch for Session Replay.

The switches are reachable from five public operations:

• POST /rum/application/remote-config/get (response config.default / config.rules[].set)
• POST /rum/application/remote-config/update (request config)
• POST /rum/application/remote-config/preview (request config, response values)
• POST /rum/application/remote-config/history/list (response items[].config)
• POST /rum/application/remote-config/history/revert

Both are emitted as "type": ["boolean", "null"], mirroring the nullability form already used by the sibling *int / *string knobs in the same schema. Optional, no default, no enum: the Go tags carry no constraint, and none was invented from the handler logic.

2. on-call — /channel/list filters are now UTF-8-validated (description update)

fc-event cmd/server/controller/channel/channel.go @ 4d425894 (PR #2411 "channel-list-utf8-query") added a check in listChannelInput.Validate(): query and channel_name are embedded into Mongo queries verbatim, so invalid UTF-8 (for example a GBK-encoded keyword) made the server reject the whole query with Location51091 — which surfaced as a 500 rather than a client error. It is now rejected with InvalidParameter. Description-only change: no OpenAPI keyword expresses UTF-8 validity, so the constraint is stated in prose next to the existing "invalid regex falls back to a literal match" note.

Files changed (6)

 api-reference/on-call.openapi.en.json |  4 ++--
 api-reference/on-call.openapi.zh.json |  4 ++--
 api-reference/openapi.en.json         | 18 ++++++++++++++++--
 api-reference/openapi.zh.json         | 18 ++++++++++++++++--
 api-reference/rum.openapi.en.json     | 14 ++++++++++++++
 api-reference/rum.openapi.zh.json     | 14 ++++++++++++++
 6 files changed, 64 insertions(+), 8 deletions(-)

Verification

• Every output file re-parses under python3 -c "import json; json.load(open(path))".
• Whole-tree deep compare of api-reference/ against HEAD: exactly 16 changed leaf paths, all intended (/components/schemas/RemoteConfigValues/properties/{sessionOnError,sessionReplayOnError} plus +; ListChannelsRequest.properties.{query,channel_name}.description plus ~, in each of the relevant files). Nothing else in any of the 12 non-legacy spec files differs.
• EN/ZH parity: identical path sets, operation keys and schema-property key order; only human-facing text differs. RemoteConfigValues and ListChannelsRequest are byte-identical (after key sort) between the module split files and the consolidated files.
• Key-order discipline: the recursively-unsorted object count is unchanged in all six files (rum 10→10, consolidated 282→282, on-call 4576→4576) — no sorting noise; the whole git diff is 64 insertions / 8 deletions.
• Operation and schema counts unchanged everywhere (consolidated: 338 paths, 728 schemas).
• api-reference/openapi.legacy.zh.json untouched (read-only reference).

unresolved (2)

1. POST /channel/incident/daily-counts (registry name channel:read:incidentDailyCounts) — no handler exists anywhere in fc-event main (grepped for the path, daily-counts and DailyCounts). Left undocumented rather than guessed, same as the previous round.
2. The 9 POST /integration/* rows — public, but no non-hidden module in the skill's mapping.yaml claims the /integration prefix, so the generator cannot pick them up; they are already documented by the still-open PR docs(api): daily audit 2026-09-25 — document the new /integration API family #472 and are not duplicated here.

Ruled out this round

• fc-rum docs(rum): align Flutter integration with production #227 session error markers (types/datadog/rum.go SampledForError / SampledForErrorReplay, cmd/engine/controller/event/view.go, model/session/session.go): ingest-side only. /rum/session-replay/metadata decodes the event and reads only eve.View.InForegroundPeriods, returning types.ReplayMetaItem, so no public response schema changes. Verified by reading cmd/server/controller/replay/metadata.go.
• fc-event #2411: validation-only, covered by change 2 above.

Examples

No operation was added, and no 200 response example was re-captured: FLASHDUTY_APP_KEY is not readable from this environment, so dev-API capture was not possible. The affected operations keep their existing hand-checked examples. The two new switches are intentionally not inserted into the remote-config/update request example — the example is a minimal payload and both switches are optional. Nothing in this diff is a machine-fabricated example value; the only authored prose is the two field descriptions, derived from the Go doc comments, plus the two UTF-8 clauses.

How this diff was produced — please read

The documented pipeline (scripts/generate_openapi.py) could not be run this round. It consumes per-module data files at .api-review/modules/*.json, which are gitignored and not present in the repo, and the team knowledge pack's restore procedure (runbooks/api-review-daily.md) together with its baseline-fidelity patch script (runbooks/api-review-apply-patches.py) are both absent — this is the 9th consecutive round blocked this way. Running the generator without those inputs drops committed paths and aborts on guard_no_path_drop(), so it was not run rather than run unsafely.

Instead the edits were applied as a verified minimal diff. Before writing, json.dumps(obj, indent=2, ensure_ascii=False) was confirmed to reproduce all six files byte-for-byte; after writing, the whole tree was deep-compared against HEAD (see Verification). The minimum-diff acceptance line is therefore met by construction. A reviewer who wants the change re-derived by the generator should expect it to emit the same two properties from the same Go source.

Script used: /opt/scripts/api-review-20260929-patch.py (dry-run by default, --apply to write).