fix(logs): avoid false-positive error level for no-error values (#4538)#122
Closed
AminDhouib wants to merge 1 commit into
Closed
fix(logs): avoid false-positive error level for no-error values (#4538)#122AminDhouib wants to merge 1 commit into
AminDhouib wants to merge 1 commit into
Conversation
…loy#4538) getLogType classified any line containing `error:` or the word `failed` as an error regardless of the value, so scheduler completion lines like `... failed: false, ..., error: none` were highlighted red. - error:/err:, failed and failure now classify as an error only when not immediately followed by a no-error value (none|null|false|nil|no|0), via negative lookahead. The exclusion is value-specific: a line such as `error: none, failed: true` is still flagged. - Bare NOTICE (no colon) is treated as info so scheduler lines short-circuit before the error branch; `notice:` stays a warning. Adds __test__/utils/log-type.test.ts covering these cases. Ports Dokploy#4539 by @brendler.
Member
Author
|
Closing as a duplicate. #68 (ports Dokploy#4594) already addresses the same issue (Dokploy#4538) and uses a more robust no-error-value check — it only clears "no-error" pairs when the value is complete (terminated by end-of-line/comma/semicolon), so genuine lines like |
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
2 participants
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.
Ports Dokploy#4539 by @brendler.
Addresses Dokploy#4538.
What
getLogTypeclassified any log line containingerror:or the wordfailedas an error, ignoring the value that follows. Job-scheduler completion lines such as:were highlighted red even though
failed: false/error: nonereport success.Changes
error:/err:,failed, andfailureclassify as an error only when not immediately followed by a no-error value (none|null|false|nil|no|0), via negative lookahead. This is value-specific, not a blanket suppressor:error: none, failed: trueis still flagged as an error.NOTICE(no colon) is treated asinfoso scheduler lines short-circuit before the error branch.notice:(with colon) is left to the warning branch, preserving existing behaviour.Verify-first (fork)
The fork's
getLogTypeinfo/error branches are byte-identical to upstream's pre-fix version, so the false positive reproduces here. Addedapps/dokploy/__test__/utils/log-type.test.ts: against the unmodified parser 3/6 cases fail (scheduler "finished" line,error: none, bareNOTICE); after the fix all 6 pass.pnpm --filter=dokploy run typecheckis clean.