The vitals samples do not say which device or Android version they hit - #201
Merged
Merged
Conversation
`issues` printed a stack trace per cluster and nothing else, because search_reports() kept reportText and dropped the rest of the report. The Reporting API sends deviceModel, osVersion and appVersion on every ErrorReport, so the data needed to tell whether a cluster is one old build on old hardware was fetched and then thrown away. The reports now come back whole and each one prints its build, API level and device. --traces controls how many of them also print the trace, so a wider --samples reads as a device spread rather than a wall of traces. That also gives a per-report versionCode, which the rates query withholds at this app's user count. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
The review found the tests could not tell --reports from a hard-coded 1. The stub returned exactly as many reports as it was asked for, so both the page size and the sample limit could be pinned to 1 with every test green. The stub now slices by the pageSize it receives, and asserts what both searches asked for. Nothing reached the argument parser either, so deleting a flag the workflow passes left the suite green and the workflow broken. build_parser() is now separate from main() and the defaults are asserted. report_identity() returned a formatted string with "?" for missing fields, which a caller wanting to count API levels would have to parse back. report_fields() returns the four values instead, None when absent, and report_lines() does the formatting. That follows rates_row and print_rates in the same file, and it prints "?" for a field that is present and null, which the string version printed as "None". --samples is renamed --reports, because it and --traces are both counts of reports and the names did not say which is which. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
…e untested Splitting report_lines() out gave it direct tests and lost the wire that feeds it. --traces could be pinned to a constant inside cmd_issues with every test green, which is the first round's finding moved one flag along. Two Issues cases now read the trace output at two different limits. The parser tests only covered the flags this PR added, so renaming --version-code, or dropping the blank choice from --by, broke a real dispatch and stayed green. The tests now read the flags out of play-vitals.yml's own case arms, which is what the class claimed to do. Also: --limit says in its help that it counts clusters, since it sits beside two flags that count reports; and the str() in the build join carries the reason it exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
xroche
added a commit
that referenced
this pull request
Sep 10, 2026
…0s (#202) PR #201 fed --reports into errorIssues:search's sampleErrorReportLimit. The first real dispatch answered: 400 'sample_error_reports' field only supports the values 0 and 1 The reports we print come from errorReports:search, whose pageSize is what --reports should drive, so the cluster search now asks for 1 whatever the flag says. The stub accepted any value, so no test could see the limit. One now pins the cluster search to 1 across three --reports values. Signed-off-by: Xavier Roche <roche@httrack.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
issuesprinted one stack trace per cluster and nothing else. The Reporting API sendsdeviceModel,osVersionandappVersionon every error report, andsearch_reports()keptreportTextand dropped the rest.Every sample now prints its build, API level and device.
--tracessays how many of them also print the trace, so a wider--reportsreads as a device spread rather than a wall of traces.This is for the
UnsatisfiedLinkErrorcluster on the 2017 build. We need to know whether those eleven users sit behind the 32-bit wall or the Android 7 one before costing a 32-bit build leg.Every mutation of the new code fails a test, except one that only differs when Play sends an empty string.