Add integration test 012: per-recipient reject codes 100/101/102 - #18
Merged
Conversation
Every existing test asserts a delivery; none asserts a per-recipient REJECTION, leaving fmsgd's validateMsgRecvForAddr ladder untested end to end and the sender-visible outcome of a bounce unverified (SPEC §10.4 step 6, §8). The ladder checks duplicate -> unknown -> accepting -> limits in order, so each case isolates one rung: send to an unseeded address (100), set carol's fmsgid accepting_new false (102), set her daily receive count limit to 0 (101). All three cross the wire from hairpin.local, since whether a recipient exists is not a header-level check — SPEC §10.3 step 3 asks only whether the recipient's domain is ours. Each code is asserted twice: on the sender's msg_to.response_code, and on to_delivery[].response_code from GET /fmsg/:id, which is the only way a client learns why a message bounced and was not covered by any test. That second assertion needs a bearer JWT, so test-lib gains api_json_get, which exchanges an API key for one the way fmsg-cli does internally. Code 101 is retryable while 100 and 102 are terminal, so non-delivery is asserted only for the 102 case. Carol's original fmsgid settings are captured up front and restored on any exit — leaving her not-accepting would break every later test involving her. Also adds test/tests-to-add.md, the running list of spec paths the suite does not yet cover, with 012 crossed off. 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.
Every existing test asserts a delivery; none asserts a per-recipient rejection, leaving fmsgd's
validateMsgRecvForAddrladder untested end to end and the sender-visible outcome of a bounce unverified (SPEC §10.4 step 6, §8).The ladder checks
duplicate -> unknown -> accepting -> limitsin order, so each case isolates one rung:100 user unknown@dave@example.com102 user not acceptingaccepting_new = false101 user fulllimit_recv_count_per_1d = 0All three cross the wire from hairpin.local: whether a recipient exists is not a header-level check — SPEC §10.3 step 3 asks only whether the recipient's domain is ours — so the header is accepted, the data downloaded, and the rejection arrives as the per-recipient response byte.
Each code is asserted twice: on the sender's
msg_to.response_code, and onto_delivery[].response_codefromGET /fmsg/:id, which is the only way a client learns why a message bounced and was covered by no test. That second assertion needs a bearer JWT, sotest-lib.shgainsapi_json_get, which exchanges an API key for one the way fmsg-cli does internally. Tests planned as 013/015/018 will reuse it.Notes on the implementation details that shaped the test:
fmsgdretryableResponseCodes) while 100 and 102 are terminal, so non-delivery is asserted only for the 102 case.Carol's original fmsgid settings are captured up front and restored via
trap ... EXIT; leaving her not-accepting would break every later test involving her.Also adds
test/tests-to-add.md, a running list of spec paths the suite does not yet cover (tiered, with rationale per item), with 012 crossed off.Full suite run locally against the podman runner: 12 passed, 0 failed.
🤖 Generated with Claude Code