User errors in alarms are marked as retryCountsAgainstLimit#6443
User errors in alarms are marked as retryCountsAgainstLimit#6443
Conversation
There was a problem hiding this comment.
I'm Bonk, and I've done a quick review of your PR.
This PR adds isExceptionJsgError to detect user-generated jsg.Error exceptions in alarm error descriptions, ensuring they count against retry limits.
Findings (by severity):
- [MEDIUM] The header comment claims the function strips
"remote."prefixes, but the implementation only strips"remote exception: "— not the"remote."prefix thatannotateBroken()can produce. The comment should match the actual behavior, or (better) the function should handle"remote."too. - [MEDIUM] Consider reusing
tunneledErrorType()instead of re-implementing prefix stripping — it already handles"remote.","expected ", and"broken."prefixes correctly, and would be more robust against future format changes. - [LOW] No unit tests for
isExceptionJsgError. The function does non-trivial string parsing with a loop; tests for the key cases (plainjsg.Error, withbroken.*prefix, withremote exception:prefix, negative cases likejsg-internal.Error,jsg.TypeError, and malformedbroken.without delimiter) would increase confidence.
This review was generated by an AI assistant and may contain inaccuracies.
|
I'm Bonk, and I've done a quick review of your PR. This PR adds Findings posted as inline review comments (by severity):
|
e376767 to
e60199e
Compare
|
The code is consistent. Both error-handling paths (the exception catch at line 540 and the output lock failure at line 609) use the same pattern with Let me verify one more subtle thing — the Looking at line 18-19 of BUILD.bazel, However, there's an issue: the test only uses symbols from Let me now check if there are any remaining issues I should flag. The comment at line 176 says "starts with 'Error'" but the code checks Let me think about whether this change needs a compat flag or autogate. This is a behavioral change in how alarm retries are classified — user-thrown
This doesn't need a compat flag because it's fixing incorrect server-side behavior, not changing the JS API contract. It also doesn't seem risky enough to need an autogate since it's narrowly scoped to All my previous review findings have been addressed. The implementation is clean, uses LGTM |
f19ad88 to
d5ba916
Compare
|
Everything looks consistent and correct. The implementation is clean, the test coverage is comprehensive, and the previous review findings have been addressed. The approach of not using LGTM |
These jsg errors are thrown from the internal system. They should be jsg-internal
Adds a isExceptionJsgError to check if an exception was generated by a user
Checks if an exception is generated from user code, and classifies it correctly.
d5ba916 to
22fb2f7
Compare
|
The implementation is clean and correct. The prefix stripping order is correct: first One subtle observation: But wait - there's actually an edge case here. If someone has I've completed my analysis. The PR is well-structured, addresses the previous review feedback, has comprehensive tests, and the behavioral changes are correct. The LGTM |
| // Returns true if the exception is a jsg.Error in one of these specific forms (after stripping | ||
| // any "remote." prefixes): plain jsg.Error, or jsg.Error inside a broken.outputGateBroken, | ||
| // broken.exceededCpu, or broken.exceededMemory annotation. Other broken prefixes are excluded. | ||
| bool isExceptionJsgError(kj::StringPtr description); |
There was a problem hiding this comment.
Is this actually any different than isTunneledException() in practice?
Even if it is, please extend tunneledErrorType() to cover what you want, and have this function call it. Currently you've implemented entirely new, separate parsing code, duplicating the code that already exists -- let's not do that.
| break; | ||
| } | ||
| } | ||
| return description.startsWith("jsg.Error:"_kj); |
There was a problem hiding this comment.
This only catches errors of type Error, not e.g. TypeError, RangeError, etc.
Per my other comment, please don't write new parsing code -- reuse the existing parsing code.
This PR adds a
isExceptionJsgErrorto check if an exception was generated by a user, marking it correctly asretryCountsAgainstLimitinrunAlarm.