Skip to content

Report rejected feature-control downloads and unreadable tunes under their own diagnostic classes - #158

Merged
Views2k merged 1 commit into
mainfrom
fix/feature-control-incident-classification
Oct 22, 2026
Merged

Views2k merged 1 commit into
mainfrom
fix/feature-control-incident-classification

Conversation

@Views2k

@Views2k Views2k commented Oct 22, 2026 •

Copy link
Copy Markdown
Owner

What

  • FeatureControlClient.ReportAcceptance: a download this PC rejected or could not keep now carries its own incident (feature-control / policy-rejected or policy-cache-unavailable, stage feature-control-refresh, with the usual health context), still once per change. Before, it was recorded without an incident, so SupplementaryObservations.EnsureClassification substituted the collector placeholder classification-missing.
  • SupplementaryIncidentSchema: the matching catalog entries (category, reasons, stage).
  • TuneCaptureService: an InvalidDataException from the tune read is reported as tune-read-failed instead of validation; Tools groups validation with clip export checks, so these showed as "Export validation failed".
  • Tests: FeatureControlTests.RejectedDownloadIsReportedOnceWithItsOwnIncident (expired envelope → one failure observation with the new incident, schema-valid), NativeTuneCaptureTests.TuneDataThatCannotBeReadIsAReadFailureNotAnExportCheck. FeatureControlTests joins the "Supplementary instrumentation" collection because the new test swaps the process-wide observer.
  • CHANGELOG: two Unreleased entries.

Why

2026-10-22 14:23:42Z: feature-control revision 2 expired on the service; the five 2.7.0 PCs online at that instant rejected it and reported the placeholder, which Tools raised as "Failure report is missing its diagnostic classification" and then "Wisp is crashing or failing on more PCs than usual". The service side is fixed (Views2k/wisp-site#352); this makes the client's report self-describing.

Order

Tools must accept the new wire values before a release that sends them: merge and deploy Views2k/wisp-site#354 first (Tools returns 400 invalid_incident for an unknown category and the app drops the batch).

Checks

  • Built on the owner's PC with SDK 8.0.426; ran FeatureControlTests, NativeTuneCaptureTests and the Supplementary instrumentation collection; dotnet format whitespace --verify-no-changes on the changed files.
  • Not exercised: a live rejection against the real service (the unit test drives the client with a signed, expired envelope through the fake transport).

…their own diagnostic classes

A feature-control download Wisp rejected or could not keep was reported without an incident,
so the collector's placeholder reached Tools as "Failure report is missing its diagnostic
classification" and, on 2026-10-22 when the service let an envelope expire, as an app-wide bug
across five PCs. The report now carries its own category (feature-control: policy-rejected,
policy-cache-unavailable; stage feature-control-refresh), still once per change.

A current tune whose data could not be read was reported with reason "validation", which Tools
groups with clip export checks ("Export validation failed"); it is a tune read failure.
@Views2k
Views2k marked this pull request as ready for review October 22, 2026 15:58
@Views2k
Views2k merged commit a867f31 into main Oct 22, 2026
14 of 15 checks passed
@Views2k
Views2k deleted the fix/feature-control-incident-classification branch October 22, 2026 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant