Summary
telemetry_sharing_recent_sends keeps the last five share attempts (time, backfill flag, window, ok, HTTP status, error class, payload) but not the destination. Settings → Usage sharing derives its receiver sentence from the newest entry (receiver_hint → receiverCopy) and shows it next to the current TELEMETRY_SHARING_URL. An operator who points TELEMETRY_SHARING_URL at a local test receiver, gets a 200, and later restores the default then reads "The receiving service acknowledged the last send" beside the production address, although the production receiver never saw that send. The data is truthful; the sentence is not (Product Quality Bar #4, honest state).
Context
Found while planning abilityai/trinity-enterprise#190 (the benchmark read). The same residue reaches the benchmark status once that lands: the client resolves the receiver's unknown answer against telemetry_sharing_last_shared_at, so a test-receiver acknowledgement makes a never-shared instance look like one whose share went missing. The one-off cleanup is DELETE /api/settings/telemetry_sharing_recent_sends and DELETE /api/settings/telemetry_sharing_last_shared_at (the prefix is DELETE-open by design, requirements §45.2 FR-7), but the log should carry the fact itself.
Acceptance Criteria
Technical Notes
- Writer:
share_now builds the entry; reader: get_status → recent_sends + receiver_hint; copy: receiverCopy in src/frontend/src/components/onboarding/telemetryConsent.js.
- Strip credentials before storing — a configured URL may carry userinfo (
src/backend/utils/url_validation.py has strip_url_credentials).
- Bounded: three files plus tests and two doc lines. Deliberately split off the abilityai/trinity-enterprise#190 client wiring so that P1 PR stays on its one acceptance criterion.
Summary
telemetry_sharing_recent_sendskeeps the last five share attempts (time, backfill flag, window,ok, HTTP status, error class, payload) but not the destination. Settings → Usage sharing derives its receiver sentence from the newest entry (receiver_hint→receiverCopy) and shows it next to the currentTELEMETRY_SHARING_URL. An operator who pointsTELEMETRY_SHARING_URLat a local test receiver, gets a 200, and later restores the default then reads "The receiving service acknowledged the last send" beside the production address, although the production receiver never saw that send. The data is truthful; the sentence is not (Product Quality Bar #4, honest state).Context
Found while planning abilityai/trinity-enterprise#190 (the benchmark read). The same residue reaches the benchmark status once that lands: the client resolves the receiver's
unknownanswer againsttelemetry_sharing_last_shared_at, so a test-receiver acknowledgement makes a never-shared instance look like one whose share went missing. The one-off cleanup isDELETE /api/settings/telemetry_sharing_recent_sendsandDELETE /api/settings/telemetry_sharing_last_shared_at(the prefix is DELETE-open by design, requirements §45.2 FR-7), but the log should carry the fact itself.Acceptance Criteria
TELEMETRY_SHARING_URLat send time (scheme + host + port; never the path's query string, never userinfo) — written by_record_sendinsrc/backend/services/telemetry_sharing_service.pyreceiver_hint/ the panel's receiver sentence names the host that answered, and says plainly when the newest entry's host differs from the currently configured onesrc/frontend/src/components/settings/TelemetrySharingPanel.vue), semantic tokens only, no new bare loading gatesystem_settingstests/unit/test_ent437_telemetry_consent.pycovers the new key and the mismatch wording;src/frontend/tests/unit/telemetryConsent.spec.jscovers the copydocs/memory/feature-flows/telemetry-sharing.md("Delivery that survives a missing receiver") and requirements §45.2 FR-5 mention the recorded destinationTechnical Notes
share_nowbuilds the entry; reader:get_status→recent_sends+receiver_hint; copy:receiverCopyinsrc/frontend/src/components/onboarding/telemetryConsent.js.src/backend/utils/url_validation.pyhasstrip_url_credentials).