fix(serverless-offline-sqs): resolve a .fifo event name against a bare ElasticMQ queue id (Fixes #189)

[silouone]

Fixes #189

What / why

When an sqs event's arn resolves to a .fifo-suffixed queue name (e.g. arn:aws:sqs:<region>:root:QueueName.fifo) but the local ElasticMQ instance is configured with the bare id QueueName (ElasticMQ does not append .fifo for a FIFO queue), GetQueueUrl({QueueName: 'QueueName.fifo'}) was rejected with QueueDoesNotExist and the listener hung — the lambda never fired. (extractQueueNameFromARN correctly preserves the suffix, which is AWS-correct; the pre-existing _getQueueUrl was dead code that only retried the same name.)

Because the emulator's naming contract is ambiguous (no single correct name), the plugin now probes both forms via a pure, exported queueNameCandidates helper: the name exactly as given first, then the toggled .fifo variant. A QueueDoesNotExist on one candidate falls through to the next; only when every candidate is genuinely missing does it keep the historical wait-for-availability delay-and-retry (so a not-yet-created queue is still awaited). #265's queueName override remains a valid workaround; this auto-resolves the root mismatch.

Credit

Thanks to @nicolaspfernandes for the detailed repro (config + elastic.conf).

Verification

Failing AVA repro written first (helper not a function + the cross-name _getQueueUrl cases hung the old same-name loop) and confirmed to FAIL on origin/master. After the fix: npx ava packages/serverless-offline-sqs/test/index.js → 124 passed (7 new #189 tests), npx eslint clean. Independently re-run by the orchestrator: green. Fully unit-verified by mocking the client — the only ElasticMQ-dependent behavior is the QueueDoesNotExist-vs-success branch — so no docker is needed.

Reviewer caveat (non-blocking)

A queue genuinely absent in both name forms (or a nil queue name from an unresolvable intrinsic) now enters the silent 10s wait-loop rather than surfacing master's immediate rejection. Matches the prior dead-code loop and the intended wait-for-availability behavior; a warning or bounded retry on candidate exhaustion would restore that visibility — possible follow-up.

🤖 Generated with Claude Code