Report the exit code the engine actually saw - #17
Merged
Conversation
Four places were turning real information into "exit code 1, category shell", which is why that pair sat at the top of the dashboard while telling nobody anything. post_update_to_api defaulted its code argument to 1 and mapped anything non-numeric to 1. Both mean "no code was passed", which is not the same fact as "the command returned 1" -- and 1 is what bash returns for every ordinary failure, so the two were indistinguishable once written. They now report 199, which says what happened. The host read the container's code with `cat flag || echo "1"`, throwing away a code it already had: lxc-attach's own return value, taken a few lines earlier. It falls back to that now. Codes 113, 114, 122, 253 and 254 are the engine asking a question and being told no. They were filed as failures, so "exit 113" -- a user declining an under-provisioned update -- was one of the largest single signatures in the data, sitting under exit code 1. They join the signal codes in reporting "aborted", and categorize_error agrees with that branch so a run is not filed as one thing and described as another. 199 is added to both copies of the table: api/exitcodes.func and the fallback in core/error_handler.func that containers use when api.func is not loaded. The header pointed at docs/exit_codes.md for keeping them in step, which does not exist; it now names what actually has to move.
Runs bootstrapped without COMMUNITY_SCRIPTS_URL fall through to scraping /proc/$$/cmdline, and the bootstrap line names only the engine. So the scrape finds "community-scripts/core", which matched no known repo and landed in the fork branch: REPO_SOURCE=external, REPO_SLUG= community-scripts/core. That is not a fork. It gave the slug its own row on the dashboard -- 4,451 runs, second only to ProxmoxVE itself -- and counted every one of them as somebody else's code. core now joins the empty case and takes the hardcoded fallback, which CI rewrites from VED to VE on promotion. Method 0 already existed to prevent this and is untouched; these are the runs where it does not apply.
Contributor
Try this branchThe engine and the scripts resolve independently, so a production script can COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/fix/telemetry-exit-codes \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVED/main/ct/debian.sh)"Swap This PR touches Run a script from a fork as wellcurl -fsSL https://raw.githubusercontent.com/community-scripts/core/fix/telemetry-exit-codes/tools/run.sh |
bash -s -- https://raw.githubusercontent.com/YOU/ProxmoxVED/your-branch ct/debian.sh \
https://raw.githubusercontent.com/community-scripts/core/fix/telemetry-exit-codesNote that Useful flags while testing
|
post_update_to_api defaulted its code argument to 1 and mapped anything non-numeric to 1, so "no code was passed" and "the command returned 1" became the same number -- and 1 is what bash returns for any ordinary failure. Both now report 199. The host read the container's code with `cat flag || echo "1"`, throwing away lxc-attach's own return value taken a few lines earlier. It falls back to that instead. 113, 114, 122, 253 and 254 are the engine asking a question and being told no. Filing them as failures is why "exit 113" was one of the largest signatures in the data, sitting under exit code 1. They now report aborted, and categorize_error agrees. 199 is added to both copies of the table, including the container fallback in core/error_handler.func.
Runs bootstrapped without COMMUNITY_SCRIPTS_URL fall through to scraping /proc/$$/cmdline, where the bootstrap line names only the engine. The scrape finds "community-scripts/core", which matched no known repo and landed in the fork branch as REPO_SOURCE=external. That gave the slug its own row on the dashboard -- 4,451 runs, second only to ProxmoxVE -- and counted them all as somebody else's code. core now joins the empty case and takes the hardcoded fallback, which CI rewrites from VED to VE on promotion.
It arrived in lib/runtime.func with #16 and the snapshot was not regenerated, so "Each loader still defines its whole API" fails on main and on every branch opened from it.
…ty-scripts/core into fix/telemetry-exit-codes
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.
✍️ Description
Four places turned real information into "exit code 1, category shell",
which is why that pair sat at the top of the dashboard telling nobody
anything.
post_update_to_apidefaulted its code argument to 1 and mappedanything non-numeric to 1. "No code was passed" and "the command
returned 1" became the same number — and 1 is what bash returns for any
ordinary failure. Both now report 199, a new code meaning exactly that.
cat flag || echo "1", throwingaway lxc-attach's own return value taken a few lines earlier. It falls
back to that instead.
told no. Filing them as failures is why
exit 113was one of thelargest signatures in the data. They now report
aborted, andcategorize_erroragrees.community-scripts/coreno longer lands in the fork branch. Runsbootstrapped without
COMMUNITY_SCRIPTS_URLscrape the bootstrap line,which names only the engine — that gave the slug its own dashboard row
(4,451 runs, second to ProxmoxVE) as
REPO_SOURCE=external.199 is in both copies of the table, including the container fallback in
core/error_handler.func.Verified with
bash -non all five files and functionally against thereal functions:
failed 113 → aborted/113,failed 1 → failed/1,failed <no code> → failed/199,core → ProxmoxVED, real fork stillexternal. shellcheck runs in CI.🔗 Related Issue
Fixes #
✅ Prerequisites (X in brackets)
API.txtwas updated to match.🤖 AI Assistance (X in brackets)
🛠️ Type of Change (X in brackets)
README,docs/,CONTRIBUTING.md, or other docs.