Skip to content

dashboard: distinguish empty results from failures - #315

Open
bhcopeland wants to merge 3 commits into
kernelci:mainfrom
bhcopeland:dashboard-empty-vs-error
Open

dashboard: distinguish empty results from failures#315
bhcopeland wants to merge 3 commits into
kernelci:mainfrom
bhcopeland:dashboard-empty-vs-error

Conversation

@bhcopeland

Copy link
Copy Markdown
Member

Two fixes to how the dashboard client reports "nothing here".

kci-dev results tests on a commit with no checkout returned "No results available for this tree/branch/commit" with no way forward. A checkout the dashboard does know returns an empty list, so the error genuinely means "no such checkout": it now says so and points at the tree listing. Closes #169.

get_issue_tests returned a tool error for any issue with no tests, which is every build-only issue: 5 of 5 sampled from a three day window. All four related-artifact lookups now share one helper instead of two treating empty as empty and two treating it as failure.

Based on #306, which needs to merge first.

Add three read-only dashboard tools, exposed both as MCP tools and on
KernelCIClient:

- get_log resolves a test's log from log_url, or a log entry in
  output_files when log_url is empty (as it is for many failures), and
  returns the decompressed text bounded to the tail by default with
  total_bytes and a truncated flag. The download streams with a bounded
  head/tail buffer, decompresses gzip incrementally, caps max_bytes at a
  hard ceiling, stops after a scan limit to bound memory, and validates
  the URL scheme and resolved address (rejecting private/link-local
  hosts and unvalidated redirects) since log URLs come from submitter
  data
- get_test_issues / get_build_issues list the issues tracked for a
  specific test or build, the inverse of the existing get_issue_tests
  and get_issue_builds

get_log is new on KernelCIClient; the issue tools expose existing client
methods that were not yet surfaced in the MCP.

The request timeout is per read rather than total, and the scan limit is
64 MiB read in 64 KiB chunks, so a slow server could hold the caller for
far longer than any single timeout suggests. Reading also stops at a
total deadline, reported as deadline_exceeded, which matters now that
tool calls run in worker threads and a stalled download occupies one.

The dashboard reports an artifact with no known issues as an error
rather than an empty list, so the two issue tools return that as an
empty list. "Nothing is tracked against this build" is the answer a
caller checking a failure wants, not a failed call. The CLI already
treats the same response that way at its own call sites.

Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
"No results available for this tree/branch/commit" does not say which of
the three values is wrong, or that the fix is to pick a commit the
dashboard knows about. A checkout it does know returns an empty list, so
the error does mean "no such checkout": say so, and point at the listing
that shows usable values.

Also drop the "json error:" prefix, which suggested a parse failure
rather than an error reported by the API.

Reported-by: Mark Brown <broonie@kernel.org>
Closes: kernelci#169
Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
The dashboard reports an artifact with nothing related to it as an
error, so get_issue_tests failed on every build-only issue: 5 of 5
sampled from a three day window, while get_issue_builds succeeded on
the same ids.

Generalise the helper added for get_test_issues and get_build_issues so
all four related-artifact lookups share it, rather than two siblings
treating an empty result as empty and two treating it as a failure.
Errors that are not "nothing related" still raise.

Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
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.

Error reporting for tests is very unclear

1 participant