Executive summary
softwaremill/elasticmq is rated At risk because critical security findings are open, most of them in the build pipeline. Its score is held back in part because 11 of the dependencies have a known vulnerability. It scores 41 out of 100, which the At risk rating leaves unchanged.
Security and Compliance, at 35, is the weakest lens and counts most in the score. The best first step is replacing the weak hashes, worth about 5 points. Raising Security and Compliance to 70 would lift the score to about 46.
Thirty-four pipeline tools are referenced by a changeable name, so the build pipeline can be tampered with. Twelve known security holes in the packages the code depends on can be used by attackers, and six settings leave the servers or containers unsafe. Pinning each tool to an exact version, updating the vulnerable packages and correcting the unsafe settings would close these risks. Limiting each secret to its own step would fix the two secrets exposed to more of the pipeline than needed, and the pipeline step that installs packages without pinning their versions needs the packages it installs pinned to exact versions. The six form fields without a label need a label.
The product code is 9,653 lines, about €13,000 to rebuild.
If Security and Compliance rose from 35 to 70, the lowest score rated Strong, the score would rise from 41 to about 46.
New since the last survey: 38 findings
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Web-Security Posture · Weak hash algorithm rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala
- Exception handling · Swallowed exception (empty catch) ui/components/queue-card.tsx
- Keyboard semantics · Modal dialog does not manage focus ui/components/create-queue-modal.tsx
- Keyboard semantics · Modal dialog does not manage focus ui/components/generate-messages-modal.tsx
- Keyboard semantics · Modal dialog does not manage focus ui/components/receive-messages-panel.tsx
- Keyboard semantics · Modal dialog does not manage focus ui/components/send-message-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/create-queue-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/create-queue-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/error-display.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/generate-messages-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/generate-messages-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/generate-messages-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/loading-skeleton.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/queue-card.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/queue-details.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/queue-details.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/queue-list.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/queue-list.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/receive-messages-panel.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/receive-messages-panel.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/send-message-modal.tsx
- Visual & motion safety · Focus outline removed inline ui/components/send-message-modal.tsx
- Visual & motion safety · Animation without a prefers-reduced-motion guard ui/components/send-message-modal.tsx
- Async & latency hygiene · Sync-over-async blocking integration-tests/nodejs/src/elasticmq-container.js
Fixed since the last survey: 8 findings
- Dependency Vulnerabilities · High CVE: REDACTED REDACTED
- Dependency Vulnerabilities · High CVE: REDACTED REDACTED
- Dependency Vulnerabilities · High CVE: [GHSA redacted] REDACTED
- Dependency Vulnerabilities · High CVE: [GHSA redacted] REDACTED
- Dependency Vulnerabilities · High CVE: [GHSA redacted] REDACTED
- Dependency Vulnerabilities · Medium CVE: REDACTED REDACTED
- Dependency Vulnerabilities · Medium CVE: REDACTED REDACTED
- Supply-chain Provenance & Signing REDACTED
Rebuild cost: about €13,000 · Estimate
| Cost to rebuild | €4,400 to €22,000, for 74 to 234 hours of work, under 0.1 person-years for one engineer |
|---|---|
| Difficulty of the problem | Standard, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×0.7 at a score of 41. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Small: 9,653 lines of product code |
| What it is not | Not a quotation: nobody has offered to build it for that. Not a valuation: it says nothing about what the business is worth. Not a certified figure: no professional has signed it as one. |
Top priorities
Diagnosis: what the measurements show together
Architecture — module dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 org.elasticmq.actor.queue.ReceiveRequestAttemptCache | 2 org.elasticmq.actor.reply | 3 org.elasticmq.persistence.TopologicalSorter | 4 org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator | 5 org.elasticmq.rest.sqs.model | 6 org.elasticmq.util | 7 ui.app.queues.[name].page | 8 ui.lib.types | 9 org.elasticmq.actor.queue.QueueActorStorage | 10 org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure | 11 org.elasticmq.actor.queue.operations.ReceiveMessageOps | 12 org.elasticmq.actor.reply.ReplySupport | 13 org.elasticmq.msg | 14 org.elasticmq.rest.sqs.AttributesModule | 15 ui.app.queues.[name] | 16 ui.components.queue-card | 17 ui.lib | 18 org.elasticmq.actor.queue.QueueActorWaitForMessagesOps | 19 org.elasticmq.actor.queue.operations | 20 ui.components | 21 org.elasticmq.actor.queue | 22 org.elasticmq | 23 org.elasticmq.actor.queue.MessageQueue | 24 org.elasticmq.actor.QueueManagerActorStorage | 25 org.elasticmq.actor.queue.QueueEvent | 26 org.elasticmq.metrics | 27 org.elasticmq.persistence | 28 org.elasticmq.rest.sqs.SendMessageDirectives | 29 org.elasticmq.actor | 30 org.elasticmq.persistence.file | 31 org.elasticmq.persistence.sql | 32 org.elasticmq.rest.sqs.SendMessageBatchDirectives | 33 org.elasticmq.rest.sqs | 34 org.elasticmq.rest.sqs.AWSProtocol | 35 org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 | 36 org.elasticmq.rest.sqs.SQSException | 37 org.elasticmq.rest.sqs.directives | 38 org.elasticmq.rest.sqs.model.RequestPayload | 39 org.elasticmq.server | 40 org.elasticmq.server.config |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 org.elasticmq.actor.queue.ReceiveRequestAttemptCache | ||||||||||||||||||||||||||||||||||||||||
| 2 org.elasticmq.actor.reply | ||||||||||||||||||||||||||||||||||||||||
| 3 org.elasticmq.persistence.TopologicalSorter | ||||||||||||||||||||||||||||||||||||||||
| 4 org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator | ||||||||||||||||||||||||||||||||||||||||
| 5 org.elasticmq.rest.sqs.model | ||||||||||||||||||||||||||||||||||||||||
| 6 org.elasticmq.util | ||||||||||||||||||||||||||||||||||||||||
| 7 ui.app.queues.[name].page | ||||||||||||||||||||||||||||||||||||||||
| 8 ui.lib.types | ||||||||||||||||||||||||||||||||||||||||
| 9 org.elasticmq.actor.queue.QueueActorStorage | 1 | 1 | 2 | |||||||||||||||||||||||||||||||||||||
| 10 org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure | 2 | |||||||||||||||||||||||||||||||||||||||
| 11 org.elasticmq.actor.queue.operations.ReceiveMessageOps | 2 | |||||||||||||||||||||||||||||||||||||||
| 12 org.elasticmq.actor.reply.ReplySupport | 1 | |||||||||||||||||||||||||||||||||||||||
| 13 org.elasticmq.msg | 2 | 2 | 10 | |||||||||||||||||||||||||||||||||||||
| 14 org.elasticmq.rest.sqs.AttributesModule | 2 | |||||||||||||||||||||||||||||||||||||||
| 15 ui.app.queues.[name] | 1 | |||||||||||||||||||||||||||||||||||||||
| 16 ui.components.queue-card | 1 | |||||||||||||||||||||||||||||||||||||||
| 17 ui.lib | 6 | |||||||||||||||||||||||||||||||||||||||
| 18 org.elasticmq.actor.queue.QueueActorWaitForMessagesOps | 1 | |||||||||||||||||||||||||||||||||||||||
| 19 org.elasticmq.actor.queue.operations | 8 | 6 | 1 | 4 | 17 | |||||||||||||||||||||||||||||||||||
| 20 ui.components | 1 | |||||||||||||||||||||||||||||||||||||||
| 21 org.elasticmq.actor.queue | 1 | 7 | 8 | 5 | 6 | 9 | ||||||||||||||||||||||||||||||||||
| 22 org.elasticmq | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 23 org.elasticmq.actor.queue.MessageQueue | 4 | |||||||||||||||||||||||||||||||||||||||
| 24 org.elasticmq.actor.QueueManagerActorStorage | 1 | |||||||||||||||||||||||||||||||||||||||
| 25 org.elasticmq.actor.queue.QueueEvent | 1 | 9 | 2 | |||||||||||||||||||||||||||||||||||||
| 26 org.elasticmq.metrics | 1 | 2 | ||||||||||||||||||||||||||||||||||||||
| 27 org.elasticmq.persistence | 2 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 28 org.elasticmq.rest.sqs.SendMessageDirectives | 2 | |||||||||||||||||||||||||||||||||||||||
| 29 org.elasticmq.actor | 4 | 3 | 1 | 3 | 2 | |||||||||||||||||||||||||||||||||||
| 30 org.elasticmq.persistence.file | 2 | 5 | 1 | |||||||||||||||||||||||||||||||||||||
| 31 org.elasticmq.persistence.sql | 1 | 3 | 3 | 1 | 5 | |||||||||||||||||||||||||||||||||||
| 32 org.elasticmq.rest.sqs.SendMessageBatchDirectives | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 33 org.elasticmq.rest.sqs | 20 | 1 | 12 | 1 | 2 | 1 | ||||||||||||||||||||||||||||||||||
| 34 org.elasticmq.rest.sqs.AWSProtocol | 1 | |||||||||||||||||||||||||||||||||||||||
| 35 org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 | 1 | |||||||||||||||||||||||||||||||||||||||
| 36 org.elasticmq.rest.sqs.SQSException | 1 | |||||||||||||||||||||||||||||||||||||||
| 37 org.elasticmq.rest.sqs.directives | 2 | 2 | 1 | 9 | ||||||||||||||||||||||||||||||||||||
| 38 org.elasticmq.rest.sqs.model.RequestPayload | 2 | 1 | ||||||||||||||||||||||||||||||||||||||
| 39 org.elasticmq.server | 2 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 40 org.elasticmq.server.config | 1 | 1 | 1 | 1 |
9→2 org.elasticmq.actor.queue.QueueActorStorage uses org.elasticmq.actor.reply✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.queue.QueueActorStorage uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.actor.queue.QueueActorStorage.ResultWithEvents→org.elasticmq.actor.reply.ReplyAction
- Direction
- org.elasticmq.actor.queue.QueueActorStorage uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.actor.queue.QueueActorStorage, while a change to org.elasticmq.actor.queue.QueueActorStorage can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.actor.queue.QueueActorStorage uses a module listed above it, which is the healthy direction.
9→6 org.elasticmq.actor.queue.QueueActorStorage uses org.elasticmq.util✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.queue.QueueActorStorage uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.actor.queue.QueueActorStorage.ResultWithEvents→org.elasticmq.util.Logging
- Direction
- org.elasticmq.actor.queue.QueueActorStorage uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.actor.queue.QueueActorStorage, while a change to org.elasticmq.actor.queue.QueueActorStorage can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.actor.queue.QueueActorStorage uses a module listed above it, which is the healthy direction.
9→21 org.elasticmq.actor.queue.QueueActorStorage uses org.elasticmq.actor.queue part of a loop✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.actor.queue.QueueActorStorage uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.actor.queue.QueueActorStorage.ResultWithEvents→org.elasticmq.actor.queue.OperationStatusorg.elasticmq.actor.queue.QueueActorStorage.ResultWithEvents→org.elasticmq.actor.queue.QueueEventWithOperationStatus
- Direction
- org.elasticmq.actor.queue.QueueActorStorage uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.actor.queue.QueueActorStorage, while a change to org.elasticmq.actor.queue.QueueActorStorage can't break org.elasticmq.actor.queue.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
10→1 org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure uses org.elasticmq.actor.queue.ReceiveRequestAttemptCache✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure uses a type in org.elasticmq.actor.queue.ReceiveRequestAttemptCache.
- The types involved
org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure.Expired→org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailureorg.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure.Invalid→org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure
- Direction
- org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure uses org.elasticmq.actor.queue.ReceiveRequestAttemptCache, so a change to org.elasticmq.actor.queue.ReceiveRequestAttemptCache can break org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure, while a change to org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure can't break org.elasticmq.actor.queue.ReceiveRequestAttemptCache.
- Position
- Below the diagonal: org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure uses a module listed above it, which is the healthy direction.
11→21 org.elasticmq.actor.queue.operations.ReceiveMessageOps uses org.elasticmq.actor.queue part of a loop✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.actor.queue.operations.ReceiveMessageOps uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.actor.queue.operations.ReceiveMessageOps.MessageToDelete→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.operations.ReceiveMessageOps.MessageToReturn→org.elasticmq.actor.queue.InternalMessage
- Direction
- org.elasticmq.actor.queue.operations.ReceiveMessageOps uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.actor.queue.operations.ReceiveMessageOps, while a change to org.elasticmq.actor.queue.operations.ReceiveMessageOps can't break org.elasticmq.actor.queue.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
12→2 org.elasticmq.actor.reply.ReplySupport uses org.elasticmq.actor.reply✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.reply.ReplySupport uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.actor.reply.ReplySupport.ReplyActorRef→org.elasticmq.actor.reply.Replyable
- Direction
- org.elasticmq.actor.reply.ReplySupport uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.actor.reply.ReplySupport, while a change to org.elasticmq.actor.reply.ReplySupport can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.actor.reply.ReplySupport uses a module listed above it, which is the healthy direction.
13→2 org.elasticmq.msg uses org.elasticmq.actor.reply✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.msg uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.msg.QueueManagerMsg→org.elasticmq.actor.reply.Replyableorg.elasticmq.msg.QueueMsg→org.elasticmq.actor.reply.Replyable
- Direction
- org.elasticmq.msg uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.msg, while a change to org.elasticmq.msg can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.msg uses a module listed above it, which is the healthy direction.
13→21 org.elasticmq.msg uses org.elasticmq.actor.queue part of a loop✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.msg uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.msg.MoveMessage→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.msg.RestoreMessages→org.elasticmq.actor.queue.InternalMessage
- Direction
- org.elasticmq.msg uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.msg, while a change to org.elasticmq.msg can't break org.elasticmq.actor.queue.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
13→22 org.elasticmq.msg uses org.elasticmq part of a loop✕
- Connections
- 10 pairs of types, where a type in org.elasticmq.msg uses a type in org.elasticmq.
- The types involved
org.elasticmq.msg.CreateQueue→org.elasticmq.CreateQueueDataorg.elasticmq.msg.DeleteMessage→org.elasticmq.DeliveryReceiptorg.elasticmq.msg.LookupMessage→org.elasticmq.MessageIdorg.elasticmq.msg.MoveMessage→org.elasticmq.MoveDestinationorg.elasticmq.msg.ReceiveMessages→org.elasticmq.VisibilityTimeoutorg.elasticmq.msg.SendMessage→org.elasticmq.NewMessageDataorg.elasticmq.msg.UpdateQueueDeadLettersQueue→org.elasticmq.DeadLettersQueueDataorg.elasticmq.msg.UpdateQueueDefaultVisibilityTimeout→org.elasticmq.MillisVisibilityTimeoutorg.elasticmq.msg.UpdateVisibilityTimeout→org.elasticmq.DeliveryReceiptorg.elasticmq.msg.UpdateVisibilityTimeout→org.elasticmq.VisibilityTimeout
- Direction
- org.elasticmq.msg uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.msg, while a change to org.elasticmq.msg can't break org.elasticmq.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
14→4 org.elasticmq.rest.sqs.AttributesModule uses org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.rest.sqs.AttributesModule uses a type in org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator.
- The types involved
org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator→org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator.Ruleorg.elasticmq.rest.sqs.AttributesModule.PossiblyEmptyAttributeValuesCalculator→org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator.Rule
- Direction
- org.elasticmq.rest.sqs.AttributesModule uses org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator, so a change to org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator can break org.elasticmq.rest.sqs.AttributesModule, while a change to org.elasticmq.rest.sqs.AttributesModule can't break org.elasticmq.rest.sqs.AttributesModule.AttributeValuesCalculator.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.AttributesModule uses a module listed above it, which is the healthy direction.
15→7 ui.app.queues.[name] uses ui.app.queues.[name].page✕
- Connections
- 1 pair of types, where a type in ui.app.queues.[name] uses a type in ui.app.queues.[name].page.
- The types involved
ui.app.queues.[name].page→ui.app.queues.[name].page.QueuePageProps
- Direction
- ui.app.queues.[name] uses ui.app.queues.[name].page, so a change to ui.app.queues.[name].page can break ui.app.queues.[name], while a change to ui.app.queues.[name] can't break ui.app.queues.[name].page.
- Position
- Below the diagonal: ui.app.queues.[name] uses a module listed above it, which is the healthy direction.
16→8 ui.components.queue-card uses ui.lib.types✕
- Connections
- 1 pair of types, where a type in ui.components.queue-card uses a type in ui.lib.types.
- The types involved
ui.components.queue-card.QueueCardProps→ui.lib.types.QueueData
- Direction
- ui.components.queue-card uses ui.lib.types, so a change to ui.lib.types can break ui.components.queue-card, while a change to ui.components.queue-card can't break ui.lib.types.
- Position
- Below the diagonal: ui.components.queue-card uses a module listed above it, which is the healthy direction.
17→8 ui.lib uses ui.lib.types✕
- Connections
- 6 pairs of types, where a type in ui.lib uses a type in ui.lib.types.
- The types involved
ui.lib.actions→ui.lib.types.QueueStatsui.lib.actions→ui.lib.types.ReceiveMessagesParamsui.lib.actions→ui.lib.types.SendBatchParamsui.lib.actions→ui.lib.types.SendBatchResultui.lib.actions→ui.lib.types.SendMessageParamsui.lib.actions→ui.lib.types.SendMessageResult
- Direction
- ui.lib uses ui.lib.types, so a change to ui.lib.types can break ui.lib, while a change to ui.lib can't break ui.lib.types.
- Position
- Below the diagonal: ui.lib uses a module listed above it, which is the healthy direction.
18→13 org.elasticmq.actor.queue.QueueActorWaitForMessagesOps uses org.elasticmq.msg✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.queue.QueueActorWaitForMessagesOps uses a type in org.elasticmq.msg.
- The types involved
org.elasticmq.actor.queue.QueueActorWaitForMessagesOps.AwaitingData→org.elasticmq.msg.ReceiveMessages
- Direction
- org.elasticmq.actor.queue.QueueActorWaitForMessagesOps uses org.elasticmq.msg, so a change to org.elasticmq.msg can break org.elasticmq.actor.queue.QueueActorWaitForMessagesOps, while a change to org.elasticmq.actor.queue.QueueActorWaitForMessagesOps can't break org.elasticmq.msg.
- Position
- Below the diagonal: org.elasticmq.actor.queue.QueueActorWaitForMessagesOps uses a module listed above it, which is the healthy direction.
19→6 org.elasticmq.actor.queue.operations uses org.elasticmq.util✕
- Connections
- 8 pairs of types, where a type in org.elasticmq.actor.queue.operations uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.util.NowProviderorg.elasticmq.actor.queue.operations.DeleteMessageOps→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.operations.MoveMessageOps→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.operations.MoveMessagesAsyncOps→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.util.NowProviderorg.elasticmq.actor.queue.operations.SendMessageOp→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps→org.elasticmq.util.Logging
- Direction
- org.elasticmq.actor.queue.operations uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.actor.queue.operations, while a change to org.elasticmq.actor.queue.operations can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.actor.queue.operations uses a module listed above it, which is the healthy direction.
19→9 org.elasticmq.actor.queue.operations uses org.elasticmq.actor.queue.QueueActorStorage✕
- Connections
- 6 pairs of types, where a type in org.elasticmq.actor.queue.operations uses a type in org.elasticmq.actor.queue.QueueActorStorage.
- The types involved
org.elasticmq.actor.queue.operations.DeleteMessageOps→org.elasticmq.actor.queue.QueueActorStorage.ResultWithEventsorg.elasticmq.actor.queue.operations.MoveMessageOps→org.elasticmq.actor.queue.QueueActorStorage.ResultWithEventsorg.elasticmq.actor.queue.operations.MoveMessagesAsyncOps→org.elasticmq.actor.queue.QueueActorStorage.ResultWithEventsorg.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.actor.queue.QueueActorStorage.ResultWithEventsorg.elasticmq.actor.queue.operations.SendMessageOp→org.elasticmq.actor.queue.QueueActorStorage.ResultWithEventsorg.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps→org.elasticmq.actor.queue.QueueActorStorage.ResultWithEvents
- Direction
- org.elasticmq.actor.queue.operations uses org.elasticmq.actor.queue.QueueActorStorage, so a change to org.elasticmq.actor.queue.QueueActorStorage can break org.elasticmq.actor.queue.operations, while a change to org.elasticmq.actor.queue.operations can't break org.elasticmq.actor.queue.QueueActorStorage.
- Position
- Below the diagonal: org.elasticmq.actor.queue.operations uses a module listed above it, which is the healthy direction.
19→11 org.elasticmq.actor.queue.operations uses org.elasticmq.actor.queue.operations.ReceiveMessageOps✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.queue.operations uses a type in org.elasticmq.actor.queue.operations.ReceiveMessageOps.
- The types involved
org.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.actor.queue.operations.ReceiveMessageOps.MessageWithDestination
- Direction
- org.elasticmq.actor.queue.operations uses org.elasticmq.actor.queue.operations.ReceiveMessageOps, so a change to org.elasticmq.actor.queue.operations.ReceiveMessageOps can break org.elasticmq.actor.queue.operations, while a change to org.elasticmq.actor.queue.operations can't break org.elasticmq.actor.queue.operations.ReceiveMessageOps.
- Position
- Below the diagonal: org.elasticmq.actor.queue.operations uses a module listed above it, which is the healthy direction.
19→21 org.elasticmq.actor.queue.operations uses org.elasticmq.actor.queue part of a loop✕
- Connections
- 4 pairs of types, where a type in org.elasticmq.actor.queue.operations uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.operations.MoveMessageOps→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.operations.SendMessageOp→org.elasticmq.actor.queue.InternalMessage
- Direction
- org.elasticmq.actor.queue.operations uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.actor.queue.operations, while a change to org.elasticmq.actor.queue.operations can't break org.elasticmq.actor.queue.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
19→22 org.elasticmq.actor.queue.operations uses org.elasticmq part of a loop✕
- Connections
- 17 pairs of types, where a type in org.elasticmq.actor.queue.operations uses a type in org.elasticmq.
- The types involved
org.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.FifoDeduplicationIdsHistoryorg.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.MillisNextDeliveryorg.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.NewMessageDataorg.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.QueueDataorg.elasticmq.actor.queue.operations.CommonOperations→org.elasticmq.VisibilityTimeoutorg.elasticmq.actor.queue.operations.DeleteMessageOps→org.elasticmq.DeliveryReceiptorg.elasticmq.actor.queue.operations.DeleteMessageOps→org.elasticmq.InvalidReceiptHandleorg.elasticmq.actor.queue.operations.MoveMessageOps→org.elasticmq.MoveDestinationorg.elasticmq.actor.queue.operations.MoveMessagesAsyncOps→org.elasticmq.ElasticMQErrororg.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.MessageDataorg.elasticmq.actor.queue.operations.ReceiveMessageOps→org.elasticmq.VisibilityTimeoutorg.elasticmq.actor.queue.operations.SendMessageOp→org.elasticmq.MessageDataorg.elasticmq.actor.queue.operations.SendMessageOp→org.elasticmq.NewMessageDataorg.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps→org.elasticmq.DeliveryReceiptorg.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps→org.elasticmq.InvalidReceiptHandleorg.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps→org.elasticmq.MillisNextDeliveryorg.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps→org.elasticmq.VisibilityTimeout
- Direction
- org.elasticmq.actor.queue.operations uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.actor.queue.operations, while a change to org.elasticmq.actor.queue.operations can't break org.elasticmq.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
20→16 ui.components uses ui.components.queue-card✕
- Connections
- 1 pair of types, where a type in ui.components uses a type in ui.components.queue-card.
- The types involved
ui.components.queue-card→ui.components.queue-card.QueueCardProps
- Direction
- ui.components uses ui.components.queue-card, so a change to ui.components.queue-card can break ui.components, while a change to ui.components can't break ui.components.queue-card.
- Position
- Below the diagonal: ui.components uses a module listed above it, which is the healthy direction.
21→1 org.elasticmq.actor.queue uses org.elasticmq.actor.queue.ReceiveRequestAttemptCache✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.queue uses a type in org.elasticmq.actor.queue.ReceiveRequestAttemptCache.
- The types involved
org.elasticmq.actor.queue.ReceiveRequestAttemptCache→org.elasticmq.actor.queue.ReceiveRequestAttemptCache.ReceiveFailure
- Direction
- org.elasticmq.actor.queue uses org.elasticmq.actor.queue.ReceiveRequestAttemptCache, so a change to org.elasticmq.actor.queue.ReceiveRequestAttemptCache can break org.elasticmq.actor.queue, while a change to org.elasticmq.actor.queue can't break org.elasticmq.actor.queue.ReceiveRequestAttemptCache.
- Position
- Below the diagonal: org.elasticmq.actor.queue uses a module listed above it, which is the healthy direction.
21→2 org.elasticmq.actor.queue uses org.elasticmq.actor.reply✕
- Connections
- 7 pairs of types, where a type in org.elasticmq.actor.queue uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.actor.queue.QueueActor→org.elasticmq.actor.reply.ReplyActionorg.elasticmq.actor.queue.QueueActor→org.elasticmq.actor.reply.ReplyingActororg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.reply.ReplyActionorg.elasticmq.actor.queue.QueueActorQueueOps→org.elasticmq.actor.reply.ReplyActionorg.elasticmq.actor.queue.QueueActorWaitForMessagesOps→org.elasticmq.actor.reply.ReplyActionorg.elasticmq.actor.queue.QueueActorWaitForMessagesOps→org.elasticmq.actor.reply.ReplyingActororg.elasticmq.actor.queue.QueueEventWithOperationStatus→org.elasticmq.actor.reply.Replyable
- Direction
- org.elasticmq.actor.queue uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.actor.queue, while a change to org.elasticmq.actor.queue can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.actor.queue uses a module listed above it, which is the healthy direction.
21→6 org.elasticmq.actor.queue uses org.elasticmq.util✕
- Connections
- 8 pairs of types, where a type in org.elasticmq.actor.queue uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.actor.queue.InternalMessage→org.elasticmq.util.NowProviderorg.elasticmq.actor.queue.QueueActor→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.QueueActor→org.elasticmq.util.NowProviderorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.util.NowProviderorg.elasticmq.actor.queue.QueueActorQueueOps→org.elasticmq.util.Loggingorg.elasticmq.actor.queue.QueueActorStorage→org.elasticmq.util.NowProviderorg.elasticmq.actor.queue.ReceiveRequestAttemptCache→org.elasticmq.util.NowProvider
- Direction
- org.elasticmq.actor.queue uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.actor.queue, while a change to org.elasticmq.actor.queue can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.actor.queue uses a module listed above it, which is the healthy direction.
21→13 org.elasticmq.actor.queue uses org.elasticmq.msg✕
- Connections
- 5 pairs of types, where a type in org.elasticmq.actor.queue uses a type in org.elasticmq.msg.
- The types involved
org.elasticmq.actor.queue.QueueActor→org.elasticmq.msg.QueueMsgorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.msg.QueueMessageMsgorg.elasticmq.actor.queue.QueueActorQueueOps→org.elasticmq.msg.QueueQueueMsgorg.elasticmq.actor.queue.QueueActorWaitForMessagesOps→org.elasticmq.msg.QueueMessageMsgorg.elasticmq.actor.queue.QueueActorWaitForMessagesOps→org.elasticmq.msg.ReceiveMessages
- Direction
- org.elasticmq.actor.queue uses org.elasticmq.msg, so a change to org.elasticmq.msg can break org.elasticmq.actor.queue, while a change to org.elasticmq.actor.queue can't break org.elasticmq.msg.
- Position
- Below the diagonal: org.elasticmq.actor.queue uses a module listed above it, which is the healthy direction.
21→19 org.elasticmq.actor.queue uses org.elasticmq.actor.queue.operations✕
- Connections
- 6 pairs of types, where a type in org.elasticmq.actor.queue uses a type in org.elasticmq.actor.queue.operations.
- The types involved
org.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.queue.operations.DeleteMessageOpsorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.queue.operations.MoveMessageOpsorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.queue.operations.MoveMessagesAsyncOpsorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.queue.operations.ReceiveMessageOpsorg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.queue.operations.SendMessageOporg.elasticmq.actor.queue.QueueActorMessageOps→org.elasticmq.actor.queue.operations.UpdateVisibilityTimeoutOps
- Direction
- org.elasticmq.actor.queue uses org.elasticmq.actor.queue.operations, so a change to org.elasticmq.actor.queue.operations can break org.elasticmq.actor.queue, while a change to org.elasticmq.actor.queue can't break org.elasticmq.actor.queue.operations.
- Position
- Below the diagonal: org.elasticmq.actor.queue uses a module listed above it, which is the healthy direction.
21→22 org.elasticmq.actor.queue uses org.elasticmq part of a loop✕
- Connections
- 9 pairs of types, where a type in org.elasticmq.actor.queue uses a type in org.elasticmq.
- The types involved
org.elasticmq.actor.queue.InternalMessage→org.elasticmq.DeduplicationIdorg.elasticmq.actor.queue.InternalMessage→org.elasticmq.MessageAttributeorg.elasticmq.actor.queue.InternalMessage→org.elasticmq.MessageContentorg.elasticmq.actor.queue.InternalMessage→org.elasticmq.MillisNextDeliveryorg.elasticmq.actor.queue.InternalMessage→org.elasticmq.Receivedorg.elasticmq.actor.queue.InternalMessage→org.elasticmq.TracingIdorg.elasticmq.actor.queue.QueueActor→org.elasticmq.QueueDataorg.elasticmq.actor.queue.QueueActorStorage→org.elasticmq.FifoDeduplicationIdsHistoryorg.elasticmq.actor.queue.QueueActorStorage→org.elasticmq.QueueData
- Direction
- org.elasticmq.actor.queue uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.actor.queue, while a change to org.elasticmq.actor.queue can't break org.elasticmq.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→6 org.elasticmq uses org.elasticmq.util✕
- Connections
- 1 pair of types, where a type in org.elasticmq uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.FifoDeduplicationIdsHistory→org.elasticmq.util.NowProvider
- Direction
- org.elasticmq uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq, while a change to org.elasticmq can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq uses a module listed above it, which is the healthy direction.
22→21 org.elasticmq uses org.elasticmq.actor.queue✕
- Connections
- 1 pair of types, where a type in org.elasticmq uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.FifoDeduplicationIdsHistory→org.elasticmq.actor.queue.InternalMessage
- Direction
- org.elasticmq uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq, while a change to org.elasticmq can't break org.elasticmq.actor.queue.
- Position
- Below the diagonal: org.elasticmq uses a module listed above it, which is the healthy direction.
23→21 org.elasticmq.actor.queue.MessageQueue uses org.elasticmq.actor.queue✕
- Connections
- 4 pairs of types, where a type in org.elasticmq.actor.queue.MessageQueue uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.actor.queue.MessageQueue.FifoMessageQueue→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.MessageQueue.FifoMessageQueue→org.elasticmq.actor.queue.MessageQueueorg.elasticmq.actor.queue.MessageQueue.SimpleMessageQueue→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.MessageQueue.SimpleMessageQueue→org.elasticmq.actor.queue.MessageQueue
- Direction
- org.elasticmq.actor.queue.MessageQueue uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.actor.queue.MessageQueue, while a change to org.elasticmq.actor.queue.MessageQueue can't break org.elasticmq.actor.queue.
- Position
- Below the diagonal: org.elasticmq.actor.queue.MessageQueue uses a module listed above it, which is the healthy direction.
24→22 org.elasticmq.actor.QueueManagerActorStorage uses org.elasticmq✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.QueueManagerActorStorage uses a type in org.elasticmq.
- The types involved
org.elasticmq.actor.QueueManagerActorStorage.ActorWithQueueData→org.elasticmq.QueueData
- Direction
- org.elasticmq.actor.QueueManagerActorStorage uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.actor.QueueManagerActorStorage, while a change to org.elasticmq.actor.QueueManagerActorStorage can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.actor.QueueManagerActorStorage uses a module listed above it, which is the healthy direction.
25→2 org.elasticmq.actor.queue.QueueEvent uses org.elasticmq.actor.reply✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor.queue.QueueEvent uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.actor.queue.QueueEvent.Restore→org.elasticmq.actor.reply.Replyable
- Direction
- org.elasticmq.actor.queue.QueueEvent uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.actor.queue.QueueEvent, while a change to org.elasticmq.actor.queue.QueueEvent can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.actor.queue.QueueEvent uses a module listed above it, which is the healthy direction.
25→21 org.elasticmq.actor.queue.QueueEvent uses org.elasticmq.actor.queue✕
- Connections
- 9 pairs of types, where a type in org.elasticmq.actor.queue.QueueEvent uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.actor.queue.QueueEvent.MessageAdded→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.QueueEvent.MessageAdded→org.elasticmq.actor.queue.QueueEventWithOperationStatusorg.elasticmq.actor.queue.QueueEvent.MessageRemoved→org.elasticmq.actor.queue.QueueEventWithOperationStatusorg.elasticmq.actor.queue.QueueEvent.MessageUpdated→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.actor.queue.QueueEvent.MessageUpdated→org.elasticmq.actor.queue.QueueEventWithOperationStatusorg.elasticmq.actor.queue.QueueEvent.QueueCreated→org.elasticmq.actor.queue.QueueEventorg.elasticmq.actor.queue.QueueEvent.QueueDeleted→org.elasticmq.actor.queue.QueueEventorg.elasticmq.actor.queue.QueueEvent.QueueMetadataUpdated→org.elasticmq.actor.queue.QueueEventorg.elasticmq.actor.queue.QueueEvent.Restore→org.elasticmq.actor.queue.QueueEvent
- Direction
- org.elasticmq.actor.queue.QueueEvent uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.actor.queue.QueueEvent, while a change to org.elasticmq.actor.queue.QueueEvent can't break org.elasticmq.actor.queue.
- Position
- Below the diagonal: org.elasticmq.actor.queue.QueueEvent uses a module listed above it, which is the healthy direction.
25→22 org.elasticmq.actor.queue.QueueEvent uses org.elasticmq✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.actor.queue.QueueEvent uses a type in org.elasticmq.
- The types involved
org.elasticmq.actor.queue.QueueEvent.QueueCreated→org.elasticmq.QueueDataorg.elasticmq.actor.queue.QueueEvent.QueueMetadataUpdated→org.elasticmq.QueueData
- Direction
- org.elasticmq.actor.queue.QueueEvent uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.actor.queue.QueueEvent, while a change to org.elasticmq.actor.queue.QueueEvent can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.actor.queue.QueueEvent uses a module listed above it, which is the healthy direction.
26→6 org.elasticmq.metrics uses org.elasticmq.util✕
- Connections
- 1 pair of types, where a type in org.elasticmq.metrics uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.metrics.QueueMetricsOps→org.elasticmq.util.NowProvider
- Direction
- org.elasticmq.metrics uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.metrics, while a change to org.elasticmq.metrics can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.metrics uses a module listed above it, which is the healthy direction.
26→22 org.elasticmq.metrics uses org.elasticmq✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.metrics uses a type in org.elasticmq.
- The types involved
org.elasticmq.metrics.QueueMetricsOps→org.elasticmq.QueueStatisticsorg.elasticmq.metrics.QueuesMetrics→org.elasticmq.QueueStatistics
- Direction
- org.elasticmq.metrics uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.metrics, while a change to org.elasticmq.metrics can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.metrics uses a module listed above it, which is the healthy direction.
27→3 org.elasticmq.persistence uses org.elasticmq.persistence.TopologicalSorter✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.persistence uses a type in org.elasticmq.persistence.TopologicalSorter.
- The types involved
org.elasticmq.persistence.TopologicalSorter→org.elasticmq.persistence.TopologicalSorter.Nodeorg.elasticmq.persistence.TopologicalSorter→org.elasticmq.persistence.TopologicalSorter.State
- Direction
- org.elasticmq.persistence uses org.elasticmq.persistence.TopologicalSorter, so a change to org.elasticmq.persistence.TopologicalSorter can break org.elasticmq.persistence, while a change to org.elasticmq.persistence can't break org.elasticmq.persistence.TopologicalSorter.
- Position
- Below the diagonal: org.elasticmq.persistence uses a module listed above it, which is the healthy direction.
27→6 org.elasticmq.persistence uses org.elasticmq.util✕
- Connections
- 1 pair of types, where a type in org.elasticmq.persistence uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.persistence.QueueSorter→org.elasticmq.util.Logging
- Direction
- org.elasticmq.persistence uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.persistence, while a change to org.elasticmq.persistence can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.persistence uses a module listed above it, which is the healthy direction.
27→22 org.elasticmq.persistence uses org.elasticmq✕
- Connections
- 1 pair of types, where a type in org.elasticmq.persistence uses a type in org.elasticmq.
- The types involved
org.elasticmq.persistence.CreateQueueMetadata→org.elasticmq.CreateQueueData
- Direction
- org.elasticmq.persistence uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.persistence, while a change to org.elasticmq.persistence can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.persistence uses a module listed above it, which is the healthy direction.
28→22 org.elasticmq.rest.sqs.SendMessageDirectives uses org.elasticmq✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.rest.sqs.SendMessageDirectives uses a type in org.elasticmq.
- The types involved
org.elasticmq.rest.sqs.SendMessageDirectives.MessageSendOutcome→org.elasticmq.MessageDataorg.elasticmq.rest.sqs.SendMessageDirectives.SendMessageActionRequest→org.elasticmq.MessageAttribute
- Direction
- org.elasticmq.rest.sqs.SendMessageDirectives uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.rest.sqs.SendMessageDirectives, while a change to org.elasticmq.rest.sqs.SendMessageDirectives can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.SendMessageDirectives uses a module listed above it, which is the healthy direction.
29→2 org.elasticmq.actor uses org.elasticmq.actor.reply✕
- Connections
- 4 pairs of types, where a type in org.elasticmq.actor uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.actor.QueueManagerActor→org.elasticmq.actor.reply.ReplyActionorg.elasticmq.actor.QueueManagerActor→org.elasticmq.actor.reply.ReplyingActororg.elasticmq.actor.QueueManagerMessageMoveOps→org.elasticmq.actor.reply.ReplyActionorg.elasticmq.actor.reply→org.elasticmq.actor.reply.ReplySupport
- Direction
- org.elasticmq.actor uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.actor, while a change to org.elasticmq.actor can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.actor uses a module listed above it, which is the healthy direction.
29→6 org.elasticmq.actor uses org.elasticmq.util✕
- Connections
- 3 pairs of types, where a type in org.elasticmq.actor uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.actor.QueueManagerActor→org.elasticmq.util.Loggingorg.elasticmq.actor.QueueManagerActor→org.elasticmq.util.NowProviderorg.elasticmq.actor.QueueManagerMessageMoveOps→org.elasticmq.util.Logging
- Direction
- org.elasticmq.actor uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.actor, while a change to org.elasticmq.actor can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.actor uses a module listed above it, which is the healthy direction.
29→13 org.elasticmq.actor uses org.elasticmq.msg✕
- Connections
- 1 pair of types, where a type in org.elasticmq.actor uses a type in org.elasticmq.msg.
- The types involved
org.elasticmq.actor.QueueManagerActor→org.elasticmq.msg.QueueManagerMsg
- Direction
- org.elasticmq.actor uses org.elasticmq.msg, so a change to org.elasticmq.msg can break org.elasticmq.actor, while a change to org.elasticmq.actor can't break org.elasticmq.msg.
- Position
- Below the diagonal: org.elasticmq.actor uses a module listed above it, which is the healthy direction.
29→22 org.elasticmq.actor uses org.elasticmq✕
- Connections
- 3 pairs of types, where a type in org.elasticmq.actor uses a type in org.elasticmq.
- The types involved
org.elasticmq.actor.QueueManagerActor→org.elasticmq.CreateQueueDataorg.elasticmq.actor.QueueManagerActor→org.elasticmq.QueueDataorg.elasticmq.actor.QueueManagerMessageMoveOps→org.elasticmq.ElasticMQError
- Direction
- org.elasticmq.actor uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.actor, while a change to org.elasticmq.actor can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.actor uses a module listed above it, which is the healthy direction.
29→24 org.elasticmq.actor uses org.elasticmq.actor.QueueManagerActorStorage✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.actor uses a type in org.elasticmq.actor.QueueManagerActorStorage.
- The types involved
org.elasticmq.actor.QueueManagerActor→org.elasticmq.actor.QueueManagerActorStorage.ActorWithQueueDataorg.elasticmq.actor.QueueManagerActorStorage→org.elasticmq.actor.QueueManagerActorStorage.ActorWithQueueData
- Direction
- org.elasticmq.actor uses org.elasticmq.actor.QueueManagerActorStorage, so a change to org.elasticmq.actor.QueueManagerActorStorage can break org.elasticmq.actor, while a change to org.elasticmq.actor can't break org.elasticmq.actor.QueueManagerActorStorage.
- Position
- Below the diagonal: org.elasticmq.actor uses a module listed above it, which is the healthy direction.
30→6 org.elasticmq.persistence.file uses org.elasticmq.util✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.persistence.file uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.persistence.file.ConfigBasedQueuePersistenceActor→org.elasticmq.util.Loggingorg.elasticmq.persistence.file.QueueConfigUtil→org.elasticmq.util.Logging
- Direction
- org.elasticmq.persistence.file uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.persistence.file, while a change to org.elasticmq.persistence.file can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.persistence.file uses a module listed above it, which is the healthy direction.
30→22 org.elasticmq.persistence.file uses org.elasticmq✕
- Connections
- 5 pairs of types, where a type in org.elasticmq.persistence.file uses a type in org.elasticmq.
- The types involved
org.elasticmq.persistence.file.ConfigBasedQueuePersistenceActor→org.elasticmq.ElasticMQErrororg.elasticmq.persistence.file.ConfigBasedQueuePersistenceActor→org.elasticmq.QueueDataorg.elasticmq.persistence.file.QueueMetadata→org.elasticmq.DeadLettersQueueDataorg.elasticmq.persistence.file.QueuePersister→org.elasticmq.DeadLettersQueueDataorg.elasticmq.persistence.file.QueuePersister→org.elasticmq.QueueData
- Direction
- org.elasticmq.persistence.file uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.persistence.file, while a change to org.elasticmq.persistence.file can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.persistence.file uses a module listed above it, which is the healthy direction.
30→27 org.elasticmq.persistence.file uses org.elasticmq.persistence✕
- Connections
- 1 pair of types, where a type in org.elasticmq.persistence.file uses a type in org.elasticmq.persistence.
- The types involved
org.elasticmq.persistence.file.QueueConfigUtil→org.elasticmq.persistence.CreateQueueMetadata
- Direction
- org.elasticmq.persistence.file uses org.elasticmq.persistence, so a change to org.elasticmq.persistence can break org.elasticmq.persistence.file, while a change to org.elasticmq.persistence.file can't break org.elasticmq.persistence.
- Position
- Below the diagonal: org.elasticmq.persistence.file uses a module listed above it, which is the healthy direction.
31→2 org.elasticmq.persistence.sql uses org.elasticmq.actor.reply✕
- Connections
- 1 pair of types, where a type in org.elasticmq.persistence.sql uses a type in org.elasticmq.actor.reply.
- The types involved
org.elasticmq.persistence.sql.GetAllMessages→org.elasticmq.actor.reply.Replyable
- Direction
- org.elasticmq.persistence.sql uses org.elasticmq.actor.reply, so a change to org.elasticmq.actor.reply can break org.elasticmq.persistence.sql, while a change to org.elasticmq.persistence.sql can't break org.elasticmq.actor.reply.
- Position
- Below the diagonal: org.elasticmq.persistence.sql uses a module listed above it, which is the healthy direction.
31→6 org.elasticmq.persistence.sql uses org.elasticmq.util✕
- Connections
- 3 pairs of types, where a type in org.elasticmq.persistence.sql uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.persistence.sql.MessageRepository→org.elasticmq.util.Loggingorg.elasticmq.persistence.sql.QueueRepository→org.elasticmq.util.Loggingorg.elasticmq.persistence.sql.SqlQueuePersistenceActor→org.elasticmq.util.Logging
- Direction
- org.elasticmq.persistence.sql uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.persistence.sql, while a change to org.elasticmq.persistence.sql can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.persistence.sql uses a module listed above it, which is the healthy direction.
31→21 org.elasticmq.persistence.sql uses org.elasticmq.actor.queue✕
- Connections
- 3 pairs of types, where a type in org.elasticmq.persistence.sql uses a type in org.elasticmq.actor.queue.
- The types involved
org.elasticmq.persistence.sql.DBMessage→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.persistence.sql.MessageRepository→org.elasticmq.actor.queue.InternalMessageorg.elasticmq.persistence.sql.SqlQueuePersistenceActor→org.elasticmq.actor.queue.OperationStatus
- Direction
- org.elasticmq.persistence.sql uses org.elasticmq.actor.queue, so a change to org.elasticmq.actor.queue can break org.elasticmq.persistence.sql, while a change to org.elasticmq.persistence.sql can't break org.elasticmq.actor.queue.
- Position
- Below the diagonal: org.elasticmq.persistence.sql uses a module listed above it, which is the healthy direction.
31→22 org.elasticmq.persistence.sql uses org.elasticmq✕
- Connections
- 1 pair of types, where a type in org.elasticmq.persistence.sql uses a type in org.elasticmq.
- The types involved
org.elasticmq.persistence.sql.SqlQueuePersistenceActor→org.elasticmq.ElasticMQError
- Direction
- org.elasticmq.persistence.sql uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.persistence.sql, while a change to org.elasticmq.persistence.sql can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.persistence.sql uses a module listed above it, which is the healthy direction.
31→27 org.elasticmq.persistence.sql uses org.elasticmq.persistence✕
- Connections
- 5 pairs of types, where a type in org.elasticmq.persistence.sql uses a type in org.elasticmq.persistence.
- The types involved
org.elasticmq.persistence.sql.CreateQueueProtocol→org.elasticmq.persistence.CreateQueueMetadataorg.elasticmq.persistence.sql.DBQueue→org.elasticmq.persistence.CreateQueueMetadataorg.elasticmq.persistence.sql.DeadLettersQueueProtocol→org.elasticmq.persistence.DeadLettersQueueorg.elasticmq.persistence.sql.QueueRepository→org.elasticmq.persistence.CreateQueueMetadataorg.elasticmq.persistence.sql.SqlQueuePersistenceActor→org.elasticmq.persistence.CreateQueueMetadata
- Direction
- org.elasticmq.persistence.sql uses org.elasticmq.persistence, so a change to org.elasticmq.persistence can break org.elasticmq.persistence.sql, while a change to org.elasticmq.persistence.sql can't break org.elasticmq.persistence.
- Position
- Below the diagonal: org.elasticmq.persistence.sql uses a module listed above it, which is the healthy direction.
32→22 org.elasticmq.rest.sqs.SendMessageBatchDirectives uses org.elasticmq✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.SendMessageBatchDirectives uses a type in org.elasticmq.
- The types involved
org.elasticmq.rest.sqs.SendMessageBatchDirectives.SendMessageBatchActionRequest→org.elasticmq.MessageAttribute
- Direction
- org.elasticmq.rest.sqs.SendMessageBatchDirectives uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.rest.sqs.SendMessageBatchDirectives, while a change to org.elasticmq.rest.sqs.SendMessageBatchDirectives can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.SendMessageBatchDirectives uses a module listed above it, which is the healthy direction.
32→28 org.elasticmq.rest.sqs.SendMessageBatchDirectives uses org.elasticmq.rest.sqs.SendMessageDirectives✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.SendMessageBatchDirectives uses a type in org.elasticmq.rest.sqs.SendMessageDirectives.
- The types involved
org.elasticmq.rest.sqs.SendMessageBatchDirectives.SendMessageBatchActionRequest→org.elasticmq.rest.sqs.SendMessageDirectives.SendMessageActionRequest
- Direction
- org.elasticmq.rest.sqs.SendMessageBatchDirectives uses org.elasticmq.rest.sqs.SendMessageDirectives, so a change to org.elasticmq.rest.sqs.SendMessageDirectives can break org.elasticmq.rest.sqs.SendMessageBatchDirectives, while a change to org.elasticmq.rest.sqs.SendMessageBatchDirectives can't break org.elasticmq.rest.sqs.SendMessageDirectives.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.SendMessageBatchDirectives uses a module listed above it, which is the healthy direction.
32→33 org.elasticmq.rest.sqs.SendMessageBatchDirectives uses org.elasticmq.rest.sqs part of a loop✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.SendMessageBatchDirectives uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.rest.sqs.SendMessageBatchDirectives.SendMessageBatchActionRequest→org.elasticmq.rest.sqs.BatchEntry
- Direction
- org.elasticmq.rest.sqs.SendMessageBatchDirectives uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.rest.sqs.SendMessageBatchDirectives, while a change to org.elasticmq.rest.sqs.SendMessageBatchDirectives can't break org.elasticmq.rest.sqs.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
33→5 org.elasticmq.rest.sqs uses org.elasticmq.rest.sqs.model✕
- Connections
- 20 pairs of types, where a type in org.elasticmq.rest.sqs uses a type in org.elasticmq.rest.sqs.model.
- The types involved
org.elasticmq.rest.sqs.AddPermissionDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.CancelMessageMoveTaskDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.ChangeMessageVisibilityBatchDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.ChangeMessageVisibilityDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.CreateQueueDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.DeleteMessageBatchDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.DeleteMessageDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.DeleteQueueDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.GetQueueUrlDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.ListDeadLetterSourceQueuesDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.ListMessageMoveTasksDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.ListQueuesDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.PurgeQueueDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.QueueAttributesDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.ReceiveMessageDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.RemovePermissionDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.SendMessageBatchDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.SendMessageDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.StartMessageMoveTaskDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.TagQueueDirectives→org.elasticmq.rest.sqs.model.RequestPayload
- Direction
- org.elasticmq.rest.sqs uses org.elasticmq.rest.sqs.model, so a change to org.elasticmq.rest.sqs.model can break org.elasticmq.rest.sqs, while a change to org.elasticmq.rest.sqs can't break org.elasticmq.rest.sqs.model.
- Position
- Below the diagonal: org.elasticmq.rest.sqs uses a module listed above it, which is the healthy direction.
33→6 org.elasticmq.rest.sqs uses org.elasticmq.util✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.rest.sqs.TheSQSRestServerBuilder→org.elasticmq.util.Logging
- Direction
- org.elasticmq.rest.sqs uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.rest.sqs, while a change to org.elasticmq.rest.sqs can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.rest.sqs uses a module listed above it, which is the healthy direction.
33→22 org.elasticmq.rest.sqs uses org.elasticmq✕
- Connections
- 12 pairs of types, where a type in org.elasticmq.rest.sqs uses a type in org.elasticmq.
- The types involved
org.elasticmq.rest.sqs.CreateQueueDirectives→org.elasticmq.CreateQueueDataorg.elasticmq.rest.sqs.MD5Util→org.elasticmq.MessageAttributeorg.elasticmq.rest.sqs.MessageAttributesSupport→org.elasticmq.MessageAttributeorg.elasticmq.rest.sqs.QueueAttributesOps→org.elasticmq.QueueDataorg.elasticmq.rest.sqs.QueueURLModule→org.elasticmq.NodeAddressorg.elasticmq.rest.sqs.ReceivedMessage→org.elasticmq.MessageAttributeorg.elasticmq.rest.sqs.SQSLimitsModule→org.elasticmq.Limitsorg.elasticmq.rest.sqs.SendMessageDirectives→org.elasticmq.MessageAttributeorg.elasticmq.rest.sqs.SendMessageDirectives→org.elasticmq.NewMessageDataorg.elasticmq.rest.sqs.SendMessageDirectives→org.elasticmq.QueueDataorg.elasticmq.rest.sqs.TheSQSRestServerBuilder→org.elasticmq.Limitsorg.elasticmq.rest.sqs.TheSQSRestServerBuilder→org.elasticmq.NodeAddress
- Direction
- org.elasticmq.rest.sqs uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.rest.sqs, while a change to org.elasticmq.rest.sqs can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.rest.sqs uses a module listed above it, which is the healthy direction.
33→27 org.elasticmq.rest.sqs uses org.elasticmq.persistence✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs uses a type in org.elasticmq.persistence.
- The types involved
org.elasticmq.rest.sqs.AutoCreateQueuesConfig→org.elasticmq.persistence.CreateQueueMetadata
- Direction
- org.elasticmq.rest.sqs uses org.elasticmq.persistence, so a change to org.elasticmq.persistence can break org.elasticmq.rest.sqs, while a change to org.elasticmq.rest.sqs can't break org.elasticmq.persistence.
- Position
- Below the diagonal: org.elasticmq.rest.sqs uses a module listed above it, which is the healthy direction.
33→28 org.elasticmq.rest.sqs uses org.elasticmq.rest.sqs.SendMessageDirectives✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.rest.sqs uses a type in org.elasticmq.rest.sqs.SendMessageDirectives.
- The types involved
org.elasticmq.rest.sqs.SendMessageDirectives→org.elasticmq.rest.sqs.SendMessageDirectives.MessageSendOutcomeorg.elasticmq.rest.sqs.SendMessageDirectives→org.elasticmq.rest.sqs.SendMessageDirectives.SendMessageActionRequest
- Direction
- org.elasticmq.rest.sqs uses org.elasticmq.rest.sqs.SendMessageDirectives, so a change to org.elasticmq.rest.sqs.SendMessageDirectives can break org.elasticmq.rest.sqs, while a change to org.elasticmq.rest.sqs can't break org.elasticmq.rest.sqs.SendMessageDirectives.
- Position
- Below the diagonal: org.elasticmq.rest.sqs uses a module listed above it, which is the healthy direction.
33→32 org.elasticmq.rest.sqs uses org.elasticmq.rest.sqs.SendMessageBatchDirectives✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs uses a type in org.elasticmq.rest.sqs.SendMessageBatchDirectives.
- The types involved
org.elasticmq.rest.sqs.SendMessageBatchDirectives→org.elasticmq.rest.sqs.SendMessageBatchDirectives.SendMessageBatchActionRequest
- Direction
- org.elasticmq.rest.sqs uses org.elasticmq.rest.sqs.SendMessageBatchDirectives, so a change to org.elasticmq.rest.sqs.SendMessageBatchDirectives can break org.elasticmq.rest.sqs, while a change to org.elasticmq.rest.sqs can't break org.elasticmq.rest.sqs.SendMessageBatchDirectives.
- Position
- Below the diagonal: org.elasticmq.rest.sqs uses a module listed above it, which is the healthy direction.
34→33 org.elasticmq.rest.sqs.AWSProtocol uses org.elasticmq.rest.sqs✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.AWSProtocol uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.rest.sqs.AWSProtocol.AWSQueryProtocol→org.elasticmq.rest.sqs.AWSProtocol
- Direction
- org.elasticmq.rest.sqs.AWSProtocol uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.rest.sqs.AWSProtocol, while a change to org.elasticmq.rest.sqs.AWSProtocol can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.AWSProtocol uses a module listed above it, which is the healthy direction.
35→33 org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 uses org.elasticmq.rest.sqs✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1.AWSJsonProtocol1.0→org.elasticmq.rest.sqs.AWSProtocol
- Direction
- org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1, while a change to org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.AWSProtocol.AWSJsonProtocol1 uses a module listed above it, which is the healthy direction.
36→33 org.elasticmq.rest.sqs.SQSException uses org.elasticmq.rest.sqs✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.SQSException uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.rest.sqs.SQSException.ElasticMQErrorOps→org.elasticmq.rest.sqs.SQSException
- Direction
- org.elasticmq.rest.sqs.SQSException uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.rest.sqs.SQSException, while a change to org.elasticmq.rest.sqs.SQSException can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.SQSException uses a module listed above it, which is the healthy direction.
37→5 org.elasticmq.rest.sqs.directives uses org.elasticmq.rest.sqs.model✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.rest.sqs.directives uses a type in org.elasticmq.rest.sqs.model.
- The types involved
org.elasticmq.rest.sqs.directives.AnyParamDirectives→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.directives.UnmatchedActionRoutes→org.elasticmq.rest.sqs.model.RequestPayload
- Direction
- org.elasticmq.rest.sqs.directives uses org.elasticmq.rest.sqs.model, so a change to org.elasticmq.rest.sqs.model can break org.elasticmq.rest.sqs.directives, while a change to org.elasticmq.rest.sqs.directives can't break org.elasticmq.rest.sqs.model.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.directives uses a module listed above it, which is the healthy direction.
37→6 org.elasticmq.rest.sqs.directives uses org.elasticmq.util✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.rest.sqs.directives uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.rest.sqs.directives.ElasticMQDirectives→org.elasticmq.util.Loggingorg.elasticmq.rest.sqs.directives.ExceptionDirectives→org.elasticmq.util.Logging
- Direction
- org.elasticmq.rest.sqs.directives uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.rest.sqs.directives, while a change to org.elasticmq.rest.sqs.directives can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.directives uses a module listed above it, which is the healthy direction.
37→22 org.elasticmq.rest.sqs.directives uses org.elasticmq✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.directives uses a type in org.elasticmq.
- The types involved
org.elasticmq.rest.sqs.directives.QueueDirectives→org.elasticmq.QueueData
- Direction
- org.elasticmq.rest.sqs.directives uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.rest.sqs.directives, while a change to org.elasticmq.rest.sqs.directives can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.directives uses a module listed above it, which is the healthy direction.
37→33 org.elasticmq.rest.sqs.directives uses org.elasticmq.rest.sqs✕
- Connections
- 9 pairs of types, where a type in org.elasticmq.rest.sqs.directives uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.rest.sqs.directives.AnyParamDirectives→org.elasticmq.rest.sqs.AWSProtocolorg.elasticmq.rest.sqs.directives.ElasticMQDirectives→org.elasticmq.rest.sqs.ActorSystemModuleorg.elasticmq.rest.sqs.directives.ElasticMQDirectives→org.elasticmq.rest.sqs.AutoCreateQueuesModuleorg.elasticmq.rest.sqs.directives.ElasticMQDirectives→org.elasticmq.rest.sqs.ContextPathModuleorg.elasticmq.rest.sqs.directives.ElasticMQDirectives→org.elasticmq.rest.sqs.QueueManagerActorModuleorg.elasticmq.rest.sqs.directives.ExceptionDirectives→org.elasticmq.rest.sqs.AWSProtocolorg.elasticmq.rest.sqs.directives.ExceptionDirectives→org.elasticmq.rest.sqs.SQSExceptionorg.elasticmq.rest.sqs.directives.RejectionDirectives→org.elasticmq.rest.sqs.AWSProtocolorg.elasticmq.rest.sqs.directives.RespondDirectives→org.elasticmq.rest.sqs.MarshallerDependencies
- Direction
- org.elasticmq.rest.sqs.directives uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.rest.sqs.directives, while a change to org.elasticmq.rest.sqs.directives can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.directives uses a module listed above it, which is the healthy direction.
38→5 org.elasticmq.rest.sqs.model.RequestPayload uses org.elasticmq.rest.sqs.model✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.rest.sqs.model.RequestPayload uses a type in org.elasticmq.rest.sqs.model.
- The types involved
org.elasticmq.rest.sqs.model.RequestPayload.JsonParams→org.elasticmq.rest.sqs.model.RequestPayloadorg.elasticmq.rest.sqs.model.RequestPayload.QueryParams→org.elasticmq.rest.sqs.model.RequestPayload
- Direction
- org.elasticmq.rest.sqs.model.RequestPayload uses org.elasticmq.rest.sqs.model, so a change to org.elasticmq.rest.sqs.model can break org.elasticmq.rest.sqs.model.RequestPayload, while a change to org.elasticmq.rest.sqs.model.RequestPayload can't break org.elasticmq.rest.sqs.model.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.model.RequestPayload uses a module listed above it, which is the healthy direction.
38→33 org.elasticmq.rest.sqs.model.RequestPayload uses org.elasticmq.rest.sqs✕
- Connections
- 1 pair of types, where a type in org.elasticmq.rest.sqs.model.RequestPayload uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.rest.sqs.model.RequestPayload.QueryParams→org.elasticmq.rest.sqs.FlatParamsReader
- Direction
- org.elasticmq.rest.sqs.model.RequestPayload uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.rest.sqs.model.RequestPayload, while a change to org.elasticmq.rest.sqs.model.RequestPayload can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.rest.sqs.model.RequestPayload uses a module listed above it, which is the healthy direction.
39→6 org.elasticmq.server uses org.elasticmq.util✕
- Connections
- 2 pairs of types, where a type in org.elasticmq.server uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.server.ElasticMQServer→org.elasticmq.util.Loggingorg.elasticmq.server.Main→org.elasticmq.util.Logging
- Direction
- org.elasticmq.server uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.server, while a change to org.elasticmq.server can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.server uses a module listed above it, which is the healthy direction.
39→22 org.elasticmq.server uses org.elasticmq✕
- Connections
- 1 pair of types, where a type in org.elasticmq.server uses a type in org.elasticmq.
- The types involved
org.elasticmq.server.ElasticMQServer→org.elasticmq.ElasticMQError
- Direction
- org.elasticmq.server uses org.elasticmq, so a change to org.elasticmq can break org.elasticmq.server, while a change to org.elasticmq.server can't break org.elasticmq.
- Position
- Below the diagonal: org.elasticmq.server uses a module listed above it, which is the healthy direction.
39→33 org.elasticmq.server uses org.elasticmq.rest.sqs✕
- Connections
- 1 pair of types, where a type in org.elasticmq.server uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.server.ElasticMQServer→org.elasticmq.rest.sqs.SQSRestServer
- Direction
- org.elasticmq.server uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.server, while a change to org.elasticmq.server can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.server uses a module listed above it, which is the healthy direction.
40→6 org.elasticmq.server.config uses org.elasticmq.util✕
- Connections
- 1 pair of types, where a type in org.elasticmq.server.config uses a type in org.elasticmq.util.
- The types involved
org.elasticmq.server.config.ElasticMQServerConfig→org.elasticmq.util.Logging
- Direction
- org.elasticmq.server.config uses org.elasticmq.util, so a change to org.elasticmq.util can break org.elasticmq.server.config, while a change to org.elasticmq.server.config can't break org.elasticmq.util.
- Position
- Below the diagonal: org.elasticmq.server.config uses a module listed above it, which is the healthy direction.
40→27 org.elasticmq.server.config uses org.elasticmq.persistence✕
- Connections
- 1 pair of types, where a type in org.elasticmq.server.config uses a type in org.elasticmq.persistence.
- The types involved
org.elasticmq.server.config.ElasticMQServerConfig→org.elasticmq.persistence.CreateQueueMetadata
- Direction
- org.elasticmq.server.config uses org.elasticmq.persistence, so a change to org.elasticmq.persistence can break org.elasticmq.server.config, while a change to org.elasticmq.server.config can't break org.elasticmq.persistence.
- Position
- Below the diagonal: org.elasticmq.server.config uses a module listed above it, which is the healthy direction.
40→31 org.elasticmq.server.config uses org.elasticmq.persistence.sql✕
- Connections
- 1 pair of types, where a type in org.elasticmq.server.config uses a type in org.elasticmq.persistence.sql.
- The types involved
org.elasticmq.server.config.ElasticMQServerConfig→org.elasticmq.persistence.sql.SqlQueuePersistenceConfig
- Direction
- org.elasticmq.server.config uses org.elasticmq.persistence.sql, so a change to org.elasticmq.persistence.sql can break org.elasticmq.server.config, while a change to org.elasticmq.server.config can't break org.elasticmq.persistence.sql.
- Position
- Below the diagonal: org.elasticmq.server.config uses a module listed above it, which is the healthy direction.
40→33 org.elasticmq.server.config uses org.elasticmq.rest.sqs✕
- Connections
- 1 pair of types, where a type in org.elasticmq.server.config uses a type in org.elasticmq.rest.sqs.
- The types involved
org.elasticmq.server.config.ElasticMQServerConfig→org.elasticmq.rest.sqs.AutoCreateQueuesConfig
- Direction
- org.elasticmq.server.config uses org.elasticmq.rest.sqs, so a change to org.elasticmq.rest.sqs can break org.elasticmq.server.config, while a change to org.elasticmq.server.config can't break org.elasticmq.rest.sqs.
- Position
- Below the diagonal: org.elasticmq.server.config uses a module listed above it, which is the healthy direction.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Accessibility
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A05:2025 — Injection | 49 | High / Critical |
| A03:2025 — Software Supply Chain Failures | 22 | High / Critical |
| A02:2025 — Security Misconfiguration | 14 | High / Critical |
Roadmap
First, replace weak MD5 and SHA1 hashes with secure alternatives like SHA-256 or non-cryptographic options depending on their specific use case. Next, resolve the 11 high-severity dependency vulnerabilities and integrate automated security scanning into the CI pipeline to prevent future regressions. Additionally, formalize disaster recovery procedures by documenting backup and geo-recovery strategies in infrastructure as code. Finally, improve accessibility by ensuring custom controls are fully keyboard-operable and correcting anchor link semantics.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Review each MD5/SHA1 use by what it protects: replace it with SHA-256+ (or a KDF for passwords) where the digest is security-relevant, and switch it to a non-cryptographic hash (xxhash, murmurhash) where it only derives an identifier such as a cache key. This repository constructs a collision-broken hash (MD5/SHA1) at 2 sites, not one: `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:392` (MessageDigest.getInstance("MD5")), `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:440` (MessageDigest.getInstance("MD5")). Each is a separate decision — fixing only the line this row cites leaves the others in place. | +4.8 pts | Medium | Web-Security Posture |
| Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (2). | +1.2 pts | Low | Static Analysis (SAST) |
| Resolve the 1 Critical vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED. | +1.2 pts | Low | Dependency Vulnerabilities |
| Resolve the 2 Critical IaC finding(s) in IaC & Container Security — start with REDACTED (2). | +1.2 pts | Low | IaC & Container Security |
| Resolve the 4 High IaC finding(s) in IaC & Container Security — start with REDACTED (2), REDACTED (2). | +1.2 pts | Low | IaC & Container Security |
| Resolve the 11 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (11). | +2.2 pts | Medium | Dependency Vulnerabilities |
| Add a SAST step to CI running what this repository's stack ships: scalafix or scapegoat — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing. | +2.2 pts | Medium | Security & performance tooling |
| Codify backups + geo-recovery in IaC and document RTO/RPO and the restore procedure — a persistence guard alone is not disaster recovery. | +2.2 pts | Medium | DR & Backup |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 0.0 | Slop | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 0.2 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 1.3 | Slop | IaC & Container Security: Critical IaC: REDACTED |
| REDACTED | 3.4 | Slop | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 5.8 | Mixed | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 5.9 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| core/src/main/scala/org/elasticmq/actor/QueueManagerActor.scala | 6.7 | Mixed | Explicit Debt: TodoComment |
| ui/components/receive-messages-panel.tsx | 7.1 | Mixed | Cyclomatic Complexity: receive-messages-panel.ReceiveMessagesPanel (cyclomatic 19) |
| ui/components/generate-messages-modal.tsx | 7.2 | Mixed | Cyclomatic Complexity: generate-messages-modal.GenerateMessagesModal (cyclomatic 44) |
| ui/components/queue-details.tsx | 7.2 | Mixed | Cyclomatic Complexity: queue-details.QueueDetails (cyclomatic 26) |
| REDACTED | 7.2 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 7.2 | Mixed | Dependency Vulnerabilities: Critical vulnerability: REDACTED |
| REDACTED | 7.2 | Mixed | IaC & Container Security: Medium IaC: REDACTED |
| ui/components/send-message-modal.tsx | 7.4 | Mixed | Cyclomatic Complexity: send-message-modal.SendMessageModal (cyclomatic 29) |
| ui/components/create-queue-modal.tsx | 7.4 | Mixed | Cyclomatic Complexity: create-queue-modal.CreateQueueModal (cyclomatic 25) |
| ui/components/queue-list.tsx | 7.4 | Mixed | Cyclomatic Complexity: queue-list.QueueList (cyclomatic 21) |
| ui/components/queue-card.tsx | 7.4 | Mixed | Cognitive Complexity: queue-card.QueueCard (cognitive 16) |
| rest/rest-sqs-testing-amazon-java-sdk/src/test/scala/org/elasticmq/rest/sqs/integration/multisdk/MessageOperationsTests.scala | 8.2 | Near-clean | Explicit Debt: TodoComment |
| rest/rest-sqs-testing-amazon-java-sdk/src/test/scala/org/elasticmq/rest/sqs/integration/common/SQSRestServerWithSdkV1Client.scala | 8.2 | Near-clean | Explicit Debt: TodoComment |
| core/src/main/scala/org/elasticmq/actor/queue/ReceiveRequestAttemptCache.scala | 8.2 | Near-clean | Explicit Debt: TodoComment |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 83 of 83 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); none rely on LLM judgement. Overall confidence is 0.9 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 83 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 234 of 259 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy · checkov | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 · 3.2.533 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | — | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D10 Test Quality — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. The 36 test(s) behind this row are the ones the JavaScript/TypeScript census could read, and this repository also carries at least 54 test source file(s) (.scala) that it cannot: it reads JavaScript/TypeScript test declarations off disk, so a JUnit/pytest-style suite is invisible to it. Skipped tests, zero-assertion tests and the other quality signals on this row are UNMEASURED in that suite — their absence from the counts above is a gap in this analyzer's language coverage, not a finding that those tests are sound.
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test reliability NOT SCORED: this repository's production source includes .scala, and the scala executor ran against the .scala half and could not be re-run to completion inside our analyzer environment — so reliability was not measured for the repository as a whole. The JavaScript/TypeScript (jest via `npm ci --ignore-scripts` in integration-tests/nodejs/ (0 tests); vitest via `npm ci --ignore-scripts` in ui/ (31 tests)): measured (0 flaky) suite(s) did re-run, and came back with 0 flaky across 1 measured tier(s) — but that is a figure for one half of the product, and we do not publish a partial one as if it were complete. This is OUR limitation, not a defect in the repo — test reliability is excluded from the score rather than counted. The remedy is our analyzer environment, not a runner nobody has built.
- D14 License Compliance — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. This repository declares REDACTED, but the licence verdict published here was taken over its sbt dependencies. Nothing was read about its npm dependencies' licensing in either direction, and a clean score on this card must not be read as covering them.
- D19 Documentation Quality — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. Each ecosystem's manifests (what makes a folder runnable or a published package) need their own proof before D19 judges its units. Until then those folders' READMEs are judged only as documents (boilerplate, structure), never counted as complete.
- D21 Naming Consistency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. D21's deterministic naming rules are gated on C# first (docs/plans/deterministic-engine.md, P5): each other language is switched on only after its own concept suite and A/B gate pass. Until then its declarations carry no naming verdict this run — this says nothing about whether its names are consistent.
- D22 Internal API Consistency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. D22 identifies the intentionally-exposed surface from `IsPackable` and `.Contracts` project names, MSBuild conventions read off the loaded project set. This target exposed no such projects, so the probe never ran; this says nothing about whether the repository has a public API. This repository commits no C#/VB source at all, so there was never an MSBuild project set to read these conventions off. That is OUR side and it is an ADMISSION gap, not an environment fault: it declares a published package (integration-tests/nodejs/package.json), but no published-package marker D22 reads admitted any project here. D22 DOES collect the public API of every language in this tree, and admits a project only when its manifest makes that ecosystem's publication act in a form the marker recognises — so what is missing is not a collector but an admission rule for the publication act this repository makes, if it makes one. The remedy is a better discriminator for that marker — not a collector, and no change to the scan image can close it. The marker's rules are measured to refuse applications, so one refused repository is the rule working as calibrated; several are the evidence that it is too strict. For npm the surface is what a published REDACTED's entry points (exports, main, module, types) export, followed through the source; an entry that names build output the tree does not commit (dist/, build/) is not followed back to source, because only a tsconfig outDir/rootDir pair states that mapping and a bundler's input lives in executable configuration this engine does not evaluate.
- D24 Comment Value — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check's reader does not cover the language this repository's product is written in, so it had nothing of the product to read. That is a gap in this analyzer's language reach — not a finding about this repository.
- D27 Navigability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Navigability is taken over call sites whose callee resolved. For C# that population includes calls into referenced assemblies; for this language only calls declared inside the repository count, so the abstention threshold reads the repository's use of its standard library as a resolution failure. That is a limit of this analyzer, not a build problem in this repository.
- D32 Data Compliance (PII/GDPR) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/BatchRequestsModule.scala` produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
- D44 Platform End-of-Life — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This dimension reads a project's own statement about the platform it runs on: a TargetFramework in a .NET project file, a .nvmrc or .python-version, a capped requires-python, a Rust toolchain file or Cargo.toml rust-version, a .go-version, .java-version, .ruby-version, .tool-versions or .sdkmanrc, a go.mod go directive, a Maven or Gradle Java level or toolchain, a Gemfile's ruby directive, a mix.exs elixir requirement, a rebar.config minimum_otp_vsn, a pubspec.yaml SDK constraint, a build.sbt scalaVersion, or a framework major pinned by a dependency constraint. This repository carries none of them, so nothing about its platform was established. That is a gap in this analyzer's coverage, NOT a finding that the platform is supported — a language whose runtime is declared elsewhere (Package.swift, a REDACTED) is simply not read here yet.
- AXR1 Runtime accessibility — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Render strategy: boot via DockerCompose (REDACTED). compose up failed (exit 18 — an image could not be pulled) — elasticmq-ui Pulling elasticmq Pulling elasticmq-ui Error Get "https://registry-1.docker.io/v2/": Forbidden elasticmq Error Get "https://registry-1.docker.io/v2/": Forbidden Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the earlier `compose pull` step reported: elasticmq Pulling elasticmq-ui Pulling elasticmq Error Get "https://registry-1.docker.io/v2/": Forbidden elasticmq-ui Error context canceled Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the runtime sandbox reaches registries only through the in-fence pull-through mirror, so an image the mirror does not carry cannot be fetched — this is a limit of our sandbox, not of your stack; runtime evidence skipped.
- C1 Data Protection — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These personal data controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks personal data controls.
- C2 Access Controls — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These authorization controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks authorization controls.
- C3 Audit Trail — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. 'scalikejdbc' is imported (persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DB.scala:2), but no entity, schema, table or model declaration this check reads was found beside it, so whether personal data is stored could not be decided.
- C4 Data Retention — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. 'scalikejdbc' is imported (persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DB.scala:2), but no entity, schema, table or model declaration this check reads was found beside it, so whether personal data is stored could not be decided.
- C5 Data-Subject Rights — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. 'scalikejdbc' is imported (persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DB.scala:2), but no entity, schema, table or model declaration this check reads was found beside it, so whether personal data is stored could not be decided.
- M4 Documentation accuracy — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. M4 checks only the claim kinds adjudicated at or above 95 % precision: links and versions (PREREGISTRATION version 9). Paths, command arguments, installs, environment variables, settings, projects, packages, routes, cd targets, infrastructure products and removed modules are read but not checked, and none of them is reported or counted.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D10 Test Quality: Assertion density is structural — it cannot tell a meaningful behavioural assertion from a trivial one, only that an assertion is present.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D16 Bus Factor: Bus-factor is a time-decayed model of commit attribution (who has recently, repeatedly worked a file), not comprehension — pairing, review and reading-without-committing spread knowledge it can't see; bot commits and shared accounts still distort it.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D19 Documentation Quality: Documentation quality publishes two things only: a runnable or packaged unit with no example, and a multi-project root README that maps none of its parts. It does not judge clarity, and its other checks (overview, licence, boilerplate, structure, empty sections, XML-doc coverage) are withheld after adjudication: their candidates are counted in the card's gaps, not shown as rows. A false statement in a document is M4's; units are .NET projects only.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
- D31 IaC & Container Security: IaC scanning checks Dockerfiles/Terraform/Kubernetes against best-practice rules — it cannot see the live cloud account, runtime configuration, or drift between the committed config and what is actually deployed.
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D43 Malicious Dependencies: Only packages some vulnerability database has already NAMED as malicious are seen — a compromise published in the last hours, or never reported at all, is invisible here, and this dimension reading 10 is not evidence that a dependency is trustworthy. There is no typosquat or dependency-confusion analysis: a package nobody has reported is simply absent from the feeds. Coverage is the dependency scan's: an ecosystem that could not be scanned is disclosed as unmeasured, never as clean.
- AC2 Forms & labels: Label association is read from static markup — a label wired up at runtime (JS-set aria-labelledby, framework-injected ids) reads as missing, a present label says nothing about whether its text is correct. A known UI-library field component (e.g. a JSX <TextField>) is now checked conservatively — flagged only when it carries NO label/aria-label/aria-labelledby/id/name — but wrapper/context-labelled libraries (Chakra/Radix FormControl+FormLabel) aren't statically visible (possible false positive) and non-JSX lowercased components are still skipped. A click handler on a plain element is now asked for a name too (it is a control the author declared), but the subtree test that answers it is deliberately generous: any DYNAMIC text expression in the subtree counts as a name, so an icon chosen by a ternary ({cond ? <IconA/> : <IconB/>}) reads as named, and a glyph component from a library the icon-import list does not know still names its parent. A clean result is "no unlabelled control found", not a labelling proof.
- AC3 Page structure: Page structure is read from the static markup tree — landmarks, headings and lang injected at runtime aren't seen, heading ORDER is checked structurally (not against the rendered visual hierarchy), and lang/title/main fire only on full documents, never partials, and the data-table check sees header-cell presence (a <th> exists), not whether each header correctly associates with its cells. Static readiness, not conformance.
- AC4 Keyboard semantics: Keyboard semantics are inferred from markup attributes — interactivity wired purely in script, focus managed at runtime, and component-level handlers are invisible. A clean result means "no static keyboard-trap shape", not a keyboard-operability proof.
- AC5 ARIA correctness: ARIA correctness is checked against the static role/attribute shape — roles/attributes set dynamically aren't seen, a valid role says nothing about whether it matches the element's real behaviour, and required-state checks are suppressed when a JSX spread could supply them. The two-branch toggle check (a control whose state is conveyed only by which of two mutually exclusive branches renders) reads CONDITIONALS THAT ARE ATTRIBUTES — Vue v-if/v-else/v-show and Alpine x-if/x-show — so the same toggle written as a Svelte {#if} block or a JSX ternary is control flow the markup model never projects as a branch and is not seen at all.
- AC6 Visual & motion safety: Contrast and motion safety are PARTIAL by construction — literal colours (hex/rgb/hsl/named) in inline styles, in-repo <style> blocks, in-repo .css files, var() tokens, Tailwind neutral utilities and CSS-in-JS top-level declarations are read (same-rule/same-element colour+background pairs only); computed/runtime/theme colour, external-CDN stylesheets, CSS-in-JS dynamic (${…}) and nested-selector colours, cross-element pairs and image contrast stay out of reach, so a clean result is bounded by what the static CSS itself shows.
- AC7 A11y enforcement: Enforcement is scored from in-repo config/CI evidence only — an a11y gate enforced in external tooling with no in-repo trace can't be credited, and a configured linter is presence, not proof the rules actually run or block a merge.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
- P5 DR & Backup: Backup/restore and disaster-recovery readiness is judged from in-repo evidence — a config that exists is not a tested restore, so the absence of positive evidence is reported as "not evidenced", never scored as present.
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
Dimensions
D1 · Cyclomatic Complexity
9 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was generate-messages-modal.GenerateMessagesModal at 44.
What to do
- Bring the 1 body over 30 down to 30 or less in Cyclomatic Complexity — start with generate-messages-modal.GenerateMessagesModal (cyclomatic 44). — Refactoring it lifts Cyclomatic Complexity from 8.2 to about 8.6/10.
- Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D2 · Cognitive Complexity
12 method(s) exceeded the cognitive complexity threshold of 15; the worst was generate-messages-modal.GenerateMessagesModal at 34.
What to do
- Bring the 1 body over 30 down to 30 or less in Cognitive Complexity — start with generate-messages-modal.GenerateMessagesModal (cognitive 34). — Refactoring it lifts Cognitive Complexity from 8.0 to about 8.2/10.
- Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D3 · God Classes
8 over-large unit(s) detected — types, modules or files that carry too much.
What to do
- Resolve the 8 FunctionTooLong finding(s) in God Classes — start with receive-messages-panel.tsx (2), send-message-modal.tsx, generate-messages-modal.tsx. — One of this dimension's main actionable groups (8 warning-level).
- Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D4 · Code Duplication
0 duplicated block group(s) detected. Measured on part of this repository only: .tsx (28% of production source) was not exposed to THIS dimension's token comparison and is not in this count; duplication there is measured by R10 Code Duplication, the frontend lens's card running the same clone algorithm over the JS/TS token stream.
D5 · Coupling
11 production modules (npm+sbt), 0 dependency cycle(s), 0 unstable depended-on module(s). Read from the build's own module declarations; a dependsOn spread (deps: _*) and a project whose directory a helper computes are not visible there; 1 module(s) off the main sequence, with abstractness counted on 8 of the 11 (the rest declare no modelled class or interface, export only macros, declare types in source no model reads, or have no source directory of their own).
What to do
- Resolve the 1 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D6 · Cohesion (LCOM4)
0 of 12 classes have LCOM4 above 3.
D9 · Test Distribution
268 test methods: 174 unit, 94 integration, 0 BDD, 0 e2e. The JavaScript/TypeScript suite contributes 36 `it`/`test` case(s) across 5 test file(s) declaring at least one; its tier split is read from package names and paths only. The Python suite contributes 4 test function(s) across 1 file(s) declaring at least one — every `def test…` in a file pytest or unittest would collect, which is those frameworks' own definition of a case; a parametrize table counts once, so this is a floor. Its tier split is read from file names and paths only. The Scala suite contributes 228 test case(s) across 37 file(s) in a test source set declaring at least one — every `test("…")`, `it("…")`, `property("…")` and `"…" in {…}` registration and every JUnit `@Test`, which is how munit, ScalaTest, utest, ZIO Test and specs2 declare a case; a case registered under a computed name is not counted, so this is a floor. Its tier split is INFERRED from paths and file names, except sbt's src/it source set, which the build declares.
D10 · Test Quality
0 skipped, 0 zero-assertion, no mocking-framework packages referenced (hand-written doubles or no mocking) across 36 tests. Measured on the JavaScript/TypeScript suite only — at least 54 test source file(s) (.scala) went unread, so its test quality is unmeasured and is not in these counts.
D12 · Dependency Hygiene
3 outdated direct sbt declarations. An sbt declaration names an EXACT version, so the remedy is an edit to the build file — there is no lockfile refresh that would move it. Test-, Provided- and it-scoped declarations are excluded, because a consumer of this project never receives them. A version held in a Scala val is read only when the val is one string literal: sbt is a program rather than a manifest, and evaluating a computed version would invent the measurement rather than take it. Whether any artifact is DEPRECATED or ABANDONED is not graded and cannot be — Maven Central publishes no such marker, and release age does not stand in for one: the most widely depended-upon libraries are routinely the stalest, being finished rather than abandoned. Known CVEs in this dependency graph are D30's question.
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
D14 · License Compliance
0 of 7 declared sbt dependency artifact(s) use a banned license. Licences were resolved from the POMs Maven Central publishes, over the production coordinates this repository's 1 sbt build file(s) (build.sbt and project/*.scala) declare with a literal version, directly or through a string-literal val — `%%` resolved to the Scala binary suffix Central publishes under, test-scoped declarations excluded — the same declaration-site closure this analysis reads for dependency currency. sbt has no lockfile a checkout carries, so this is deliberately NOT the transitive closure. 14 further production coordinate(s) are declared with a version the build computes rather than writes as a literal — sbt is a program, and this pass does not run it — and are NOT graded: this verdict covers what the build pins literally or through a string-literal val, not the full graph. ★ COVERAGE OF THIS VERDICT: it grades this repository's sbt dependencies and nothing else. The repository also declares REDACTED, and the licences of those dependencies were NOT read by this pass — a gap in this engine's coverage, not a statement about them. So this result says the graded closure carries no banned licence; it does NOT say this repository's licensing is clear.
D15 · Churn × Complexity Hotspots
No churn × complexity hotspots in the window.
D16 · Bus Factor
3 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is ui/components/queue-details.tsx. Counted over 54 of the 142 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
D17 · Explicit Debt
4 deducted task-comment markers across 9653 LoC (0.0/KLoC) → score 9.9. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
What to do
- Resolve the 4 TodoComment finding(s) in Explicit Debt — start with MessageOperationsTests.scala, SQSRestServerWithSdkV1Client.scala, QueueManagerActor.scala. — One of this dimension's main actionable groups (4 warning-level).
- Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D19 · Documentation Quality
1 of 1 documentation facets pass in full. 2 document(s) read across 1 unit(s).
D20 · ADR Quality
No architecture decision records were found.
What to do
- Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).
D26 · Project Cohesion
1 of 2 build units (npm, sbt) flagged as possibly oversized/incoherent.
What to do
- Resolve the 1 Projects may be oversized for their cohesion finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
D29 · Static Analysis (SAST)
49 finding(s): 0 critical, 37 high, 12 medium, 0 low. 34 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens. semgrep hit a parse error in 1 file(s) — `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/BatchRequestsModule.scala` — so no absence of findings in them is evidence of anything, and nothing in them was analysed. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them. Separately, one or more rules could not re-parse an embedded snippet in 1 file(s) (e.g. a workflow `run:` block read as shell). Those files WERE scanned and their other rows are unaffected; only those rules' view of those snippets is missing.
What to do
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (2). — One of this dimension's main actionable groups (2 issue-level).
- No action in Static Analysis (SAST) — all 31 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (31 issue-level, 0 of them charged here).
- No action in Static Analysis (SAST) — all 3 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (3 issue-level, 0 of them charged here).
D30 · Dependency Vulnerabilities
17 finding(s): 1 critical, 11 high, 4 medium, 1 low.
What to do
- Resolve the 11 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (11). — One of this dimension's main actionable groups (11 issue-level).
- Resolve the 1 Critical vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 3 Medium CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (3). — One of this dimension's main actionable groups (3 warning-level).
D31 · IaC & Container Security
14 finding(s): 2 critical, 4 high, 5 medium, 3 low.
What to do
- Resolve the 4 High IaC finding(s) in IaC & Container Security — start with REDACTED (2), REDACTED (2). — One of this dimension's main actionable groups (4 issue-level).
- Resolve the 2 Critical IaC finding(s) in IaC & Container Security — start with REDACTED (2). — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 5 Medium IaC finding(s) in IaC & Container Security — start with REDACTED (5). — One of this dimension's main actionable groups (5 warning-level).
D34 · Knowledge Freshness
30 of 54 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is ui/components/generate-messages-modal.tsx. Counted over 54 of the 142 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
What to do
- Resolve the 28 Orphaned file finding(s) in Knowledge Freshness — start with receive-messages-panel.tsx, create-queue-modal.tsx, MessageQueue.scala. — One of this dimension's main actionable groups (28 recommendation-level).
- Resolve the 2 Most significant orphaned file finding(s) in Knowledge Freshness — start with generate-messages-modal.tsx, send-message-modal.tsx. — One of this dimension's main actionable groups (2 recommendation-level).
- Resolve the 1 Concentrated knowledge decay finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
D35 · Change Coupling
Strongest change-coupling: QueueActorMessageOps.scala↔QueueActorQueueOps.scala 56%
What to do
- Resolve the 1 Change coupling finding(s) in Change Coupling — start with QueueActorMessageOps.scala. — One of this dimension's main actionable groups (1 warning-level).
D36 · Supply-chain Provenance & Signing
1/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
What to do
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
D43 · Malicious Dependencies
No dependency in any ecosystem this repository declares is published as malicious.
Frontend & cross-cutting dimensions
AC2 · Forms & labels
- This <div> carries a click handler, which makes it a control, but it has no text, aria-label or labelled child (the icon-only case), so assistive tech has no name to announce for it. Note that switching it to <button type="button"> — the right fix for its keyboard operability — does not give it a name either: an icon-only button still needs one. Add visible text or an aria-label. (×4) — ui/components/create-queue-modal.tsx:74, ui/components/generate-messages-modal.tsx:135, ui/components/receive-messages-panel.tsx:270, …
- This control has only a placeholder — a placeholder is not a label (it vanishes on input and many AT ignore it). Add a <label htmlFor>, a wrapping <label>, or aria-label. (×4) — ui/components/generate-messages-modal.tsx:324, ui/components/generate-messages-modal.tsx:328, ui/components/send-message-modal.tsx:307, …
- This control has no associated label. Add a <label htmlFor> / wrapping <label> / aria-label / aria-labelledby so assistive tech can name it. (×2) — ui/components/generate-messages-modal.tsx:325, ui/components/send-message-modal.tsx:313
What to do
- Give every control a programmatic label (a <label for> / wrapping <label> / aria-label) and every button text — a placeholder is not a label.
AC3 · Page structure
- No <main> (or role="main") means no "skip to content" target and a weaker landmark map. Wrap the primary content in <main>. — ui/app/layout.tsx:33
- A <table> with data cells but no <th> gives assistive technology no way to associate cells with their headers. Mark the header row/column cells as <th> (with a scope). — ui/components/queue-details.tsx:205
What to do
- Declare <html lang>, a document <title> and a <main> landmark, keep headings in order, leave zoom enabled, title iframes and drop meta-refresh.
AC4 · Keyboard semantics
- A click handler on a plain element with no role and no tabindex: even where another element's key handler can reach it, assistive tech can neither focus it nor announce what it is. Use a <button>, or add role + tabIndex={0}. — ui/components/create-queue-modal.tsx:74
- This <div role="dialog"> is a modal dialog, but focus is moved into it, but nothing keeps it there: Tab walks out to the page behind, so a keyboard or screen-reader user keeps acting on the content behind it (WCAG 2.4.3). Use a native <dialog> opened with showModal(), a dialog component that traps focus, or move focus to the dialog on open, trap Tab inside it (or make the page behind inert) and return focus to the control that opened it on close. (×3) — ui/components/create-queue-modal.tsx:86, ui/components/generate-messages-modal.tsx:142, ui/components/send-message-modal.tsx:128
- A click handler on a plain element isn't keyboard-operable. Use a <button>, or add role + tabIndex={0} + a key handler. (×3) — ui/components/generate-messages-modal.tsx:135, ui/components/receive-messages-panel.tsx:270, ui/components/send-message-modal.tsx:116
- This <div> binds mouse-enter and mouse-leave and nothing else — no click, no key handler, no focus handler, and no tabIndex={0}, so it cannot even take focus. A keyboard user cannot hover, so whatever the pair reveals or highlights is reachable with a mouse only. Bind the same state to focus/blur as well, and add tabIndex={0}="0" so the element can receive that focus. — ui/components/queue-card.tsx:26
- This <div role="dialog"> is a modal dialog, but nothing moves focus into it when it opens and nothing keeps focus inside it while it is open, so a keyboard or screen-reader user keeps acting on the content behind it (WCAG 2.4.3). Use a native <dialog> opened with showModal(), a dialog component that traps focus, or move focus to the dialog on open, trap Tab inside it (or make the page behind inert) and return focus to the control that opened it on close. — ui/components/receive-messages-panel.tsx:282
What to do
- Make custom controls keyboard-operable (role + tabindex + key handler), drop positive tabindex, and give anchors a real href.
AC5 · ARIA correctness
AC6 · Visual & motion safety
- <div> moves — its inline style sets `transition: transform 220ms cubic-bezier(0.34,1.56,0.64,1), opacity 200ms ease` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. (×3) — ui/components/create-queue-modal.tsx:97, ui/components/generate-messages-modal.tsx:147, ui/components/send-message-modal.tsx:139
- <span> moves — its inline style sets `transition: transform 160ms ease` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. (×4) — ui/components/create-queue-modal.tsx:319, ui/components/generate-messages-modal.tsx:430, ui/components/receive-messages-panel.tsx:103, …
- <div> moves — its inline style sets `animation: fadeUp 300ms ease both` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. (×4) — ui/components/error-display.tsx:10, ui/components/queue-card.tsx:26, ui/components/queue-details.tsx:95, …
- <div> moves — its inline style sets `transition: width 200ms ease` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. — ui/components/generate-messages-modal.tsx:230
- <div> moves — its inline style sets `animation: shimmer 1.6s ease-in-out infinite` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. — ui/components/loading-skeleton.tsx:36
- <span> moves — its inline style sets `animation: autoRefreshDisabled` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. (×2) — ui/components/queue-details.tsx:120, ui/components/queue-list.tsx:95
- <div> moves — its inline style sets `transition: transform 250ms cubic-bezier(0.32,0.72,0,1)` — and nothing reads prefers-reduced-motion for it, so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Gate it on @media (prefers-reduced-motion: no-preference) or motion-safe:. — ui/components/receive-messages-panel.tsx:282
- <textarea> takes keyboard focus, and outline:none/0 in its inline style removes the focus ring with no chance of a :focus replacement (an inline style outranks every stylesheet rule). Keep a visible focus indicator. — ui/components/send-message-modal.tsx:245
What to do
- Keep a visible focus style (don't remove the outline without a replacement), guard animation with prefers-reduced-motion, and raise low-contrast colour pairs to at least 4.5:1.
AC7 · A11y enforcement
- No accessibility enforcement found — no a11y linter (eslint-plugin-jsx-a11y) and no axe/pa11y/Lighthouse in tests or CI. Start with the linter to catch issues at author time. What was searched, so you can tell an absence from a miss: the 15 markup file(s) this pass actually assessed, the linter configuration checked in beside them, and this repository's test and CI files — matched by name against the accessibility checkers this dimension carries. An audit run outside the repository, a hosted scanner, or a check whose name is not one of those, is not seen here.
What to do
- Enforce accessibility in the toolchain: add eslint-plugin-jsx-a11y, then assert with vitest-axe in tests, then gate axe/pa11y/Lighthouse in CI.
AX10 · Code composition
What to do
- The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
AX2 · Stateful singletons
AX3 · Project dependency cycles
AX4 · Dependency direction
AX6 · Interface segregation
AX8 · Test isolation
GD1 · Unfinished & placeholder code
IC1 · Incompleteness & stubs
M1 · Documentation (README)
What to do
- Add a README to the 1 of 2 project(s) that lack one — worth up to 1 pts.
M2 · Architecture documentation
- No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
What to do
- Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
M3 · Folder & project structure
M4 · Documentation accuracy
P1 · CI/CD gates
P2 · Observability
- Only 1/2 runnable modules use logging (modules with no entry point or server are excluded — they are libraries a runnable module hosts). Silent: `ui`.
What to do
- Extend structured logging to the remaining runnable modules so everything you run is diagnosable in production.
- Consider OpenTelemetry tracing/metrics (opentelemetry-java or Micrometer) and a health-check endpoint (Spring Boot Actuator's /actuator/health, or a /health route) for operability.
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add scalafix or scapegoat (or `semgrep --config=auto`, which runs on any language) as a CI step. What was searched, so you can tell an absence from a miss: the 18995 CI workflow file(s) in this repository, and the scanner and linter configuration checked in beside them. A scan that runs outside CI, one configured in your forge's web UI rather than in a committed file, or a tool whose name is none of those this check carries, is not seen — if that is your case the row is wrong, and saying so is more useful than adding a second scanner.
What to do
- Add a SAST step to CI running what this repository's stack ships: scalafix or scapegoat — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing.
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P4 · Deployment & Rollback
- Deployment is orchestrated by compose, but no service declares a `healthcheck:` and nothing pins a previous image to fall back to — the runtime can tell that the container is up, not that it is serving, so a bad release is harder to detect and reverse.
- Deployment is automated and no gate that pauses it for a human is DECLARED IN THIS REPOSITORY'S PIPELINE FILES. What was read: every file under `.github/workflows/`, `.forgejo/workflows/`, `.gitea/workflows/`, `.azuredevops/` and `.azure-pipelines/`, plus `.gitlab-ci*` and `azure-pipelines*` — with comment text stripped, so documenting a gate is not declaring one. What would have counted: GitLab's `when: manual`, CircleCI's `type: approval`, an Azure `ManualValidation@` task or an `approvals:` block, a Jenkins `input` step, a `uses:` step naming an approval action, an `environment:` paired with `reviewers` / `required_reviewers` / `protection` / `wait-timer` / `deployment_branch_policy`, a draft-release step, a `workflow_dispatch` promotion, or a release-event gate. ★ What this cannot see, because none of it is a file: a GitHub environment whose required reviewers are configured in repo SETTINGS, a branch protection rule, or an organisation deployment policy — all of them real, enforced gates that live outside the repository. If yours is one of those, this row is wrong and nothing in the tree could have told us. Otherwise: whatever reaches the release trigger goes to production unreviewed, so a mistaken merge or tag is live before anyone can stop it.
What to do
- Add a `healthcheck:` to the served compose service — probing the endpoint it already answers on where it has one — with `depends_on: condition: service_healthy` on whatever waits for it, and keep the deployed image tag immutable and recorded so rolling back is re-pointing at the previous tag rather than rebuilding.
- Add an approval/environment gate (required reviewers / protection rules) before production promotion.
P5 · DR & Backup
- A persistence guard (data volume / purge-protection) was found, but no backup, geo-recovery or RTO/RPO controls were evidenced — a volume that survives a container recreate is not a tested restore from catastrophic loss.
What to do
- Codify backups + geo-recovery in IaC and document RTO/RPO and the restore procedure — a persistence guard alone is not disaster recovery.
P6 · Release Hygiene
PF3 · Async & latency hygiene
- `existsSync` in `start` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×2) — integration-tests/nodejs/src/elasticmq-container.js:83, integration-tests/nodejs/src/elasticmq-container.js:90
What to do
- TypeScript/JavaScript: use the promise APIs (fs/promises, a promisified child_process.execFile, the async zlib/crypto functions) and await them instead of the *Sync variants.
R1 · Type Safety
What to do
- Migrate the remaining .js/.jsx files to TypeScript.
R10 · Code Duplication
- ui/components/create-queue-modal.tsx:69 · ui/components/send-message-modal.tsx:111 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/create-queue-modal.tsx:69
- ui/components/generate-messages-modal.tsx:130 · ui/components/send-message-modal.tsx:111 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/generate-messages-modal.tsx:130
- ui/components/generate-messages-modal.tsx:345 · ui/components/send-message-modal.tsx:365 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/generate-messages-modal.tsx:345
- ui/components/generate-messages-modal.tsx:302 · ui/components/send-message-modal.tsx:277 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/generate-messages-modal.tsx:302
- ui/components/queue-details.tsx:24 · ui/components/queue-list.tsx:15 — the two spans are one implementation copied and then locally edited — 164 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ui/components/queue-details.tsx:24
- ui/components/create-queue-modal.tsx:325 · ui/components/send-message-modal.tsx:483 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/create-queue-modal.tsx:325
- ui/components/generate-messages-modal.tsx:8 · ui/components/send-message-modal.tsx:8 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/generate-messages-modal.tsx:8
- ui/components/create-queue-modal.tsx:12 · ui/components/send-message-modal.tsx:32 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/create-queue-modal.tsx:12
- ui/components/create-queue-modal.tsx:29 · ui/components/send-message-modal.tsx:54 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it. — ui/components/create-queue-modal.tsx:29
- ui/components/create-queue-modal.tsx:274 · ui/components/generate-messages-modal.tsx:414 · ui/components/send-message-modal.tsx:451 — the 3 copies are spread across 3 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/create-queue-modal.tsx:274
- ui/components/generate-messages-modal.tsx:414 · ui/components/send-message-modal.tsx:451 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/generate-messages-modal.tsx:414
- ui/components/generate-messages-modal.tsx:37 · ui/components/send-message-modal.tsx:36 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it. — ui/components/generate-messages-modal.tsx:37
- ui/components/create-queue-modal.tsx:208 · ui/components/send-message-modal.tsx:349 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/create-queue-modal.tsx:208
- ui/components/generate-messages-modal.tsx:199 · ui/components/send-message-modal.tsx:203 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/generate-messages-modal.tsx:199
- ui/components/generate-messages-modal.tsx:329 · ui/components/send-message-modal.tsx:342 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/generate-messages-modal.tsx:329
- ui/components/queue-details.tsx:308 · ui/components/queue-details.tsx:322 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/queue-details.tsx:308
- ui/components/create-queue-modal.tsx:132 · ui/components/receive-messages-panel.tsx:314 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/create-queue-modal.tsx:132
- ui/components/create-queue-modal.tsx:246 · ui/components/send-message-modal.tsx:410 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/create-queue-modal.tsx:246
- ui/components/generate-messages-modal.tsx:176 · ui/components/send-message-modal.tsx:182 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — ui/components/generate-messages-modal.tsx:176
- ui/components/generate-messages-modal.tsx:59 · ui/components/receive-messages-panel.tsx:234 — the two spans are one implementation copied and then locally edited — 80 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ui/components/generate-messages-modal.tsx:59
- ui/components/generate-messages-modal.tsx:68 · ui/components/send-message-modal.tsx:78 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ui/components/generate-messages-modal.tsx:68
What to do
- Act on each finding's own remediation rather than one rule: the move depends on what recurs. Where the copies are executable blocks, give the shared part one home and call it from each site; where they are declarations, a listing, a specialisation already delegating to its base, or one shape repeated per entity, there is no call site and the move is a shared type, a generated set or a factory — sometimes there is nothing to extract.
R2 · Cyclomatic Complexity
- GenerateMessagesModal has cyclomatic complexity 33 and cognitive complexity 30; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/generate-messages-modal.tsx:29
- SendMessageModal has cyclomatic complexity 19 and cognitive complexity 17; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/send-message-modal.tsx:32
- QueueDetails has cyclomatic complexity 16 and cognitive complexity 15; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/queue-details.tsx:22
- QueueList has cyclomatic complexity 15 and cognitive complexity 14; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/queue-list.tsx:14
- ReceiveMessagesPanel has cyclomatic complexity 15 and cognitive complexity 12; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/receive-messages-panel.tsx:219
- CreateQueueModal has cyclomatic complexity 14 and cognitive complexity 12; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/create-queue-modal.tsx:12
- sendMessage has cyclomatic complexity 13 and cognitive complexity 16; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — REDACTED:103
- createQueue has cyclomatic complexity 13 and cognitive complexity 13; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — REDACTED:244
- MessageCard has cyclomatic complexity 13 and cognitive complexity 12; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/receive-messages-panel.tsx:36
- CardBtn has cyclomatic complexity 13 and cognitive complexity 10; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/queue-card.tsx:134
- QueueCard has cyclomatic complexity 12 and cognitive complexity 11; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ui/components/queue-card.tsx:16
What to do
- Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5.
R3 · Large Files
- ui/components/send-message-modal.tsx has 460 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ui/components/send-message-modal.tsx:1
- ui/components/receive-messages-panel.tsx has 457 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ui/components/receive-messages-panel.tsx:1
- ui/components/generate-messages-modal.tsx has 410 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ui/components/generate-messages-modal.tsx:1
What to do
- Split each oversized file along the responsibilities already in it, into smaller focused modules in the same package.
R4 · Test Coverage
- No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one. (×10) — ui/components/receive-messages-panel.tsx:1, ui/components/queue-details.tsx:1, ui/components/queue-list.tsx:1, …
What to do
- Add tests that import the unreached modules (directly or through their public entry).
R5 · Dependency Freshness
What to do
- Bump outdated dependencies to current versions to limit upgrade debt.
R6 · Tooling
R7 · Dead Code
- 3 file(s) (~370 LoC) were excluded from dead-code analysis. This package DOES declare main/module/exports — but every declared target is missing from the scanned tree, which is what a build-output entry (dist/, lib/, out/) looks like before the package is built. Point a declared target at the source entry, or build the package before scanning, so reachability can follow it. — integration-tests/nodejs
R8 · Dependency Hygiene
R9 · Circular Imports
S1 · Web-Security Posture
- MD5/SHA1 is computed here, and both are collision-broken. If this digest protects anything — a signature, an integrity or tamper check, a credential, or any value an attacker can influence — that is a real weakness: use SHA-256+ (`MessageDigest.getInstance("SHA-256")`) for content integrity, or a KDF (bcrypt/Argon2/scrypt) for password storage. If it only derives a non-security identifier (a cache key, an avatar URL, an ETag), collision resistance carries no security consequence here; make that intent explicit instead — a non-cryptographic hash such as xxhash or murmurhash says it in code — since the algorithm alone cannot distinguish the two uses. Where a protocol this code does not own fixes the digest (a k-anonymity range query, a legacy signature format), the protocol decides; say so beside the call. (×2) — rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:392, rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:440
- This repository runs an HTTP server and nothing in its Scala source or committed configuration secures the transport: no HTTPS served (akka/pekko-http `ConnectionContext.httpsServer`/`enableHttps`, an http4s builder's `withTLS`, Jetty's `SslContextFactory`, zio-http's `SSLConfig`, Play's `https.port`), no `Strict-Transport-Security` header, HSTS middleware or Play `RedirectHttpsFilter`, no `X-Forwarded-Proto` read or Play `play.http.forwarded.trustedProxies` for a TLS-terminating proxy — so its traffic may cross the network in clear text. (−2.0 on this card.) The server: rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:330 — `newServerAt`.
- None of the 11 security response headers the OWASP Secure Headers Project recommends (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, …) is set on a response this repository's Scala server sends — defense in depth, even when a proxy could set them. (−2.0 on this card.) The server: rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:330 — `newServerAt`.
- No handler of this repository's Scala server answers 400, 413 or 422 (`BadRequest`, `StatusCodes.BadRequest`, `Status.BadRequest`, `UnprocessableEntity`), and nothing declares validation — no Play `Form(mapping(…))` or `validate[T]`, no tapir `Validator`, no akka/pekko-http `validate(…)` or `withSizeLimit`, no validation library (refined, iron, accord, cats `Validated`, Jakarta Bean Validation) — nothing shows inbound requests being checked, and refused, before a handler acts on them. A check that answers its failure with 200 and an error body is not seen. (−2.0 on this card.) The server: rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:330 — `newServerAt`.
What to do
- Review each MD5/SHA1 use by what it protects: replace it with SHA-256+ (or a KDF for passwords) where the digest is security-relevant, and switch it to a non-cryptographic hash (xxhash, murmurhash) where it only derives an identifier such as a cache key. This repository constructs a collision-broken hash (MD5/SHA1) at 2 sites, not one: `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:392` (MessageDigest.getInstance("MD5")), `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:440` (MessageDigest.getInstance("MD5")). Each is a separate decision — fixing only the line this row cites leaves the others in place.
- Secure the server's transport: serve TLS itself (akka/pekko-http `ConnectionContext.httpsServer(sslContext)` with `newServerAt(…).enableHttps(…)`, an http4s server builder's `withTLS(…)`, Play's `https.port`), or run it behind a TLS-terminating proxy and trust it (`X-Forwarded-Proto`; Play `play.http.forwarded.trustedProxies`); send `Strict-Transport-Security` once it is HTTPS-only (http4s `HSTS(…)`, Play `RedirectHttpsFilter`).
- Set security response headers on what the server sends — keep Play's `SecurityHeadersFilter` enabled, wrap akka/pekko-http routes in `respondWithHeaders(RawHeader("X-Content-Type-Options", "nosniff"), …)`, or add an http4s middleware that sets `Content-Security-Policy`, `X-Content-Type-Options` and a frame policy on every response.
- Validate what the server reads from a request — path, query, headers, body size and shape — and answer what fails with 400 (413 for an oversized body) before a handler acts on it: a Play form or `validate[T]` answered with `BadRequest`, tapir `Validator`s on the endpoint's inputs, or akka/pekko-http's `validate(…)` and `withSizeLimit` directives.
X1 · Async correctness
X12 · Unreachable branch
X13 · Undrained process stream
X14 · Bypassable address classification
X15 · Unvalidated length from an untrusted reader
X16 · Unfloored truncation loop
X17 · Uncapped recursion over a caller-supplied document
X18 · Disposal-pattern correctness
X19 · Unrestored process-global state
X20 · Mistyped argument guard
X21 · Side-effecting pattern guard
X22 · Contradicted release guard
X23 · Unguarded diagnostic materialisation
X24 · Document value interpolated into markup unescaped
X25 · Inert configuration knob
X26 · Unsynchronised callback handoff
X27 · Collection changed while being enumerated
X28 · Index access outside its own emptiness guard
X29 · Per-element action decided by a fixed element
X3 · Exception handling
- An empty catch block silently discards the error — failures vanish with no log and no rethrow. Log it, handle it, or don't catch it. — ui/components/queue-card.tsx:107
What to do
- Swallowed exception (empty catch)
X30 · Support guard that admits what it rejects
X5 · Nullable reference types
- No build over this repository's 118 Scala product file(s) passes `-Yexplicit-nulls`, enables WartRemover's `Null` wart or runs Scalafix's `DisableSyntax.noNulls`, so every reference type admits null and nothing reports a `null` written into the code or returned from a Java API — the first one to reach a method call is a `NullPointerException`. `Option` by convention is a habit no tool here holds the code to.
What to do
- On Scala 3, add `-Yexplicit-nulls` to `scalacOptions` so `String` and `String | Null` mean different things, and type each Java API's result as nullable where it can return null; on Scala 2 (or as a first step), enable WartRemover's `Null` wart (`wartremoverErrors += Wart.Null`) or Scalafix's `DisableSyntax.noNulls = true` so the code holds absence in `Option`. Then pay the assertions down rather than adding to them: each `.nn` is a null the compiler could not rule out — wrap the Java value in `Option(…)` at the boundary, pattern-match on `null` once there, or change the API so the null cannot arrive; an `unsafeNulls` import switches the checking off for everything after it.
WCAG coverage — what static analysis assessed
| Dimension | WCAG 2.2 A/AA criteria | Coverage |
|---|---|---|
| AC2 · Forms & labels | 1.3.1, 3.3.2, 4.1.2 | Partial signal |
| AC3 · Page structure | 1.4.4, 2.2.1, 2.4.1, 2.4.2, 3.1.1, 4.1.2 | Partial signal |
| AC4 · Keyboard semantics | 2.1.1, 2.4.3 | Partial signal |
| AC5 · ARIA correctness | 4.1.2 | Partial signal |
| AC6 · Visual & motion safety | 1.4.3, 2.4.7 | Partial — literal CSS only |
| AC7 · A11y enforcement | enforcement — no page criterion | Enforcement posture (process) |
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 55% | Adequate — gated by X5 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Architecture | 90% | Adequate — gated by D26 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Maturity | 67% | Adequate — gated by M2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 37% | Weak — gated by P3, P5 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 35% | Weak — gated by D29, D30, D36, S1 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Accessibility | 41% | Weak — gated by AC4 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Performance | 70% | Strong | Strongest area. |
Unscored — 1 check(s) recorded observations but carry no score
- X7 Silent fallback defaults — 1 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 3 control(s) we could not find positive evidence for
- C3 Audit Trail — Not assessed: this repository stores data through 'scalikejdbc' (persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DB.scala:2) but declares no persisted model this check reads (Slick table columns, CREATE TABLE and ALTER TABLE … ADD columns in SQL migrations). Personal data may be written through raw SQL or a hosted backend, so whether its changes need an audit trail could not be established, and the trail's absence is not scored.
- C4 Data Retention — Not assessed: this repository stores data through 'scalikejdbc' (persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DB.scala:2) but declares no persisted model this check reads (Slick table columns, CREATE TABLE and ALTER TABLE … ADD columns in SQL migrations). Personal data may be written through raw SQL or a hosted backend, so whether a retention limit applies here could not be established, and its absence is not scored.
- C5 Data-Subject Rights — Not assessed: this repository stores data through 'scalikejdbc' (persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DB.scala:2) but declares no persisted model this check reads (Slick table columns, CREATE TABLE and ALTER TABLE … ADD columns in SQL migrations). Personal data may be written through raw SQL or a hosted backend, so whether data-subject rights apply here could not be established, and their absence is not scored.
Not included — 44 check(s) not relevant to this codebase
- AC1 Text alternatives — No image/media element found in the parsed markup — AC1 not applicable here.
- AX1 Captive dependencies — Not applicable: this repository's Java imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's; this repository's JavaScript imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's; this repository's Scala imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's; this repository's TypeScript imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's.
- AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AX9 CQS / query purity — no CQRS query handlers detected — query purity is not applicable to this codebase
- AXB2 Runtime readiness — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- AXR1 Runtime accessibility — compose up failed (exit 18 — an image could not be pulled) — elasticmq-ui Pulling elasticmq Pulling elasticmq-ui Error Get "https://registry-1.docker.io/v2/": Forbidden elasticmq Error Get "https://registry-1.docker.io/v2/": Forbidden Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the earlier `compose pull` step reported: elasticmq Pulling elasticmq-ui Pulling elasticmq Error Get "https://registry-1.docker.io/v2/": Forbidden elasticmq-ui Error context canceled Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the runtime sandbox reaches registries only through the in-fence pull-through mirror, so an image the mirror does not carry cannot be fetched — this is a limit of our sandbox, not of your stack; runtime evidence skipped This is a statement about this run, not a statement about your application: nothing here says the surface is inaccessible, only that it was never rendered.
- C1 Data Protection — Not assessed: these personal data controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks personal data controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C2 Access Controls — Not assessed: these authorization controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks authorization controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- D11 Test Reliability — Test reliability not scored — polyglot repository, one half's runner produced no measurement
- D18 Solution Shape — D18 scores the shape of a .NET solution; this repository has no .NET solution or project files, so the dimension does not apply.
- D21 Naming Consistency — Naming consistency is measured on C# only; Java, JavaScript, Scala, TypeScript not measured.
- D22 Internal API Consistency — The exposed public-API surface could not be collected — no C#/VB projects loaded.
- D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D24 Comment Value — D24 reads C# and Visual Basic comments only — this repository's production source is .java, .scala, .ts, .tsx, which was left unread. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D25 ADR Conformance — no ADRs to check
- D27 Navigability — D27 counts a call into the standard library or a dependency as unresolved for this repository's language (.scala), so too few call sites counted as resolved to assess navigability. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D32 Data Compliance (PII/GDPR) — 1 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D39 IL Efficiency — D39 measures the IL emitted by a .NET build; this repository has no .NET solution or project files, so the dimension does not apply.
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D44 Platform End-of-Life — Platform end-of-life not assessed — this repository declares no platform this pass reads
- D7 Architectural Integrity — no checkable ADRs, and no project-reference graph for the cycle pass to read — so this dimension makes no claim about dependency cycles in either direction (where this repository's language has an import-cycle lens, cycles are reported there). Architectural integrity not assessed
- D8 Code Coverage — Coverage NOT MEASURED: the JavaScript/TypeScript half could not be measured — the jest suite in integration-tests/nodejs/ ran and not one test passed (FAIL test/basic.test.js), so the coverage report describes the failed run, not the code. Coverage is excluded from the score rather than counted as a near-zero. The named suite step is one the repository's maintainers can perform; once it passes, the real number is measured on the next scan. Alternatively, commit the lcov/Cobertura report your CI produces and it is read without a re-run.
- DM1 Domain Modelling — applicable but not scored (2 signals for this style, 2 needed — the count is met but a required primary signal is absent): 94 value object(s); 5 domain event(s); its domain events are published by services or handlers — no domain entity raises one
- ED1 Event-Driven — not scored — this repository shows none of the 3 signals this lens looks for
- ED5 Idempotency — no mutating command handlers or message consumers detected — idempotency check not applicable
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- P7 Outbound HTTP resilience — not applicable — no HTTP server, API framework or worker entry point was found in the JVM, JavaScript/TypeScript source, so there is no service whose uptime a failing dependency could take down
- P8 Schema migrations — no ORM, schema-migration tool or schema auto-create was found in this repository's dependency manifests or source, so there is no database schema for this check to judge
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (`addSbtPlugin("org.scoverage" % "sbt-scoverage" % "<version>")` in `project/plugins.sbt`, then `sbt clean coverage test coverageReport`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Not applicable: no benchmark suite was found. This check searched for `@Benchmark` in a Java, Kotlin or Scala file importing JMH or kotlinx-benchmark, Jetpack Benchmark's `measureRepeated` in a file importing androidx.benchmark, or JMH/kotlinx-benchmark/androidx.benchmark in a pom.xml, Gradle or sbt build, and for a `*benchmark*` script that this repository's CI runs. Benchmarks are credited as a bonus, so their absence is neither scored nor deducted.
- PF2 Allocation hygiene — Not applicable: allocation awareness is rated where code engineers for it — at least 400 production lines that ship benchmarks or already use allocation-aware idioms (8 or more). This repository's Java and Scala code has 7,720 production line(s), 7 such use(s) and no benchmarks, so there is no allocation work to rate. The card is reward-only: its absence costs nothing.
- R11 Import Boundaries — No recognizable feature-sliced/layered src layout — boundary rules not applicable.
- SC1 Supply-chain hygiene — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X10 Duplicated predicate — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X2 Cancellation propagation — no C# was loaded; this repository's Scala and Java were read, and no request in it can be cancelled by a caller — a Scala request takes no token: a Future cannot be cancelled, and cats-effect, ZIO and Monix interrupt the fiber that made the request from outside the call, not through a parameter; a Java request off Android takes no token: it is cancelled through the handle it returns (Future.cancel, Call.cancel, a Disposable), ambiently (io.grpc.Context) or by interrupting its thread, not through a parameter
- X32 Type resolved by simple name across every loaded assembly — This check is about how a .NET program searches the assemblies loaded into its process for a type, and this repository contains no .NET source, so there is nothing here for it to assess. Not a gap in the analyzer and not a finding about your code.
- X4 Structured logging — This check asks whether log calls keep a message's values apart from its text, which needs a logger that can carry them as fields. This repository's Java was read, and it logs through none that an assembled message defeats: java.util.logging's level methods, log4j 1, commons-logging, JBoss Logging and Flogger take one finished message (as log4net does in C#), or it makes no call through a named logger at all. Calls made through SLF4J or log4j 2 (`org.slf4j.Logger`, `org.apache.logging.log4j.Logger`, Lombok's `@Slf4j`) would be judged.
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 70 finding(s)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Custom control with no accessible name on <div> ui/components/create-queue-modal.tsx:74
- Custom control with no accessible name on <div> ui/components/generate-messages-modal.tsx:135
- Custom control with no accessible name on <div> ui/components/receive-messages-panel.tsx:270
- Custom control with no accessible name on <div> ui/components/send-message-modal.tsx:116
- <input> without a programmatic label ui/components/generate-messages-modal.tsx:324
- <input> without a programmatic label ui/components/generate-messages-modal.tsx:328
- <input> without a programmatic label ui/components/send-message-modal.tsx:307
- <input> without a programmatic label ui/components/send-message-modal.tsx:330
- Click handler on a non-interactive <div> ui/components/create-queue-modal.tsx:74
- Click handler on a non-interactive <div> ui/components/generate-messages-modal.tsx:135
- Click handler on a non-interactive <div> ui/components/receive-messages-panel.tsx:270
- Click handler on a non-interactive <div> ui/components/send-message-modal.tsx:116
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- <select> without a programmatic label ui/components/generate-messages-modal.tsx:325
- <select> without a programmatic label ui/components/send-message-modal.tsx:313
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Hover-only interaction on <div> ui/components/queue-card.tsx:26
- REDACTED
- REDACTED
Serious — 134 finding(s)
- Animation without a prefers-reduced-motion guard ui/components/create-queue-modal.tsx:97
- Animation without a prefers-reduced-motion guard ui/components/create-queue-modal.tsx:319
- Animation without a prefers-reduced-motion guard ui/components/error-display.tsx:10
- Animation without a prefers-reduced-motion guard ui/components/generate-messages-modal.tsx:147
- Animation without a prefers-reduced-motion guard ui/components/generate-messages-modal.tsx:230
- Animation without a prefers-reduced-motion guard ui/components/generate-messages-modal.tsx:430
- Animation without a prefers-reduced-motion guard ui/components/loading-skeleton.tsx:36
- Animation without a prefers-reduced-motion guard ui/components/queue-card.tsx:26
- Animation without a prefers-reduced-motion guard ui/components/queue-details.tsx:95
- Animation without a prefers-reduced-motion guard ui/components/queue-details.tsx:120
- Animation without a prefers-reduced-motion guard ui/components/queue-list.tsx:50
- Animation without a prefers-reduced-motion guard ui/components/queue-list.tsx:95
- Animation without a prefers-reduced-motion guard ui/components/receive-messages-panel.tsx:103
- Animation without a prefers-reduced-motion guard ui/components/receive-messages-panel.tsx:282
- Animation without a prefers-reduced-motion guard ui/components/send-message-modal.tsx:139
- Animation without a prefers-reduced-motion guard ui/components/send-message-modal.tsx:477
- No test reaches this file ui/components/receive-messages-panel.tsx:1
- No test reaches this file ui/components/queue-details.tsx:1
- No test reaches this file ui/components/queue-list.tsx:1
- No test reaches this file ui/lib/theme-provider.tsx:1
- No test reaches this file ui/components/page-header.tsx:1
- No test reaches this file ui/components/loading-skeleton.tsx:1
- No test reaches this file ui/components/theme-switcher.tsx:1
- No test reaches this file ui/app/layout.tsx:1
- No test reaches this file ui/app/queues/[name]/page.tsx:1
- No test reaches this file ui/app/page.tsx:1
- FunctionTooLong: send-message-modal.SendMessageModal ui/components/send-message-modal.tsx:32
- FunctionTooLong: generate-messages-modal.GenerateMessagesModal ui/components/generate-messages-modal.tsx:29
- FunctionTooLong: create-queue-modal.CreateQueueModal ui/components/create-queue-modal.tsx:12
- FunctionTooLong: queue-details.QueueDetails ui/components/queue-details.tsx:22
- FunctionTooLong: receive-messages-panel.ReceiveMessagesPanel ui/components/receive-messages-panel.tsx:219
- FunctionTooLong: receive-messages-panel.MessageCard ui/components/receive-messages-panel.tsx:36
- FunctionTooLong: queue-list.QueueList ui/components/queue-list.tsx:14
- FunctionTooLong: queue-card.QueueCard ui/components/queue-card.tsx:16
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Modal dialog does not manage focus ui/components/create-queue-modal.tsx:86
- Modal dialog does not manage focus ui/components/generate-messages-modal.tsx:142
- Modal dialog does not manage focus ui/components/receive-messages-panel.tsx:282
- Modal dialog does not manage focus ui/components/send-message-modal.tsx:128
- TodoComment rest/rest-sqs-testing-amazon-java-sdk/src/test/scala/org/elasticmq/rest/sqs/integration/multisdk/MessageOperationsTests.scala:98
- TodoComment rest/rest-sqs-testing-amazon-java-sdk/src/test/scala/org/elasticmq/rest/sqs/integration/common/SQSRestServerWithSdkV1Client.scala:78
- TodoComment core/src/main/scala/org/elasticmq/actor/QueueManagerActor.scala:25
- TodoComment core/src/main/scala/org/elasticmq/actor/queue/ReceiveRequestAttemptCache.scala:21
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Sync-over-async blocking integration-tests/nodejs/src/elasticmq-container.js:83
- Sync-over-async blocking integration-tests/nodejs/src/elasticmq-container.js:90
- Duplicated block (15 lines × 2 locations) ui/components/create-queue-modal.tsx:12
- Duplicated block (15 lines × 2 locations) ui/components/create-queue-modal.tsx:29
- Duplicated block (12 lines × 2 locations) ui/components/create-queue-modal.tsx:208
- Duplicated block (12 lines × 2 locations) ui/components/generate-messages-modal.tsx:199
- Duplicated block (9 lines × 2 locations) ui/components/generate-messages-modal.tsx:329
- Duplicated block (9 lines × 2 locations) ui/components/queue-details.tsx:308
- Duplicated block (8 lines × 2 locations) ui/components/create-queue-modal.tsx:132
- Duplicated block (8 lines × 2 locations) ui/components/create-queue-modal.tsx:246
- Weak hash algorithm rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:392
- Weak hash algorithm rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:440
- Page without a main landmark ui/app/layout.tsx:33
- Data table has no header cells ui/components/queue-details.tsx:205
- Focus outline removed inline ui/components/send-message-modal.tsx:245
- Accessibility enforcement below the top rung
- generate-messages-modal.GenerateMessagesModal (cyclomatic 44) ui/components/generate-messages-modal.tsx:29
- send-message-modal.SendMessageModal (cyclomatic 29) ui/components/send-message-modal.tsx:32
- queue-details.QueueDetails (cyclomatic 26) ui/components/queue-details.tsx:22
- create-queue-modal.CreateQueueModal (cyclomatic 25) ui/components/create-queue-modal.tsx:12
- SendMessageDirectives.createMessage (cyclomatic 22) rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SendMessageDirectives.scala:76
- queue-list.QueueList (cyclomatic 21) ui/components/queue-list.tsx:14
- receive-messages-panel.ReceiveMessagesPanel (cyclomatic 19) ui/components/receive-messages-panel.tsx:219
- receive-messages-panel.MessageCard (cyclomatic 17) ui/components/receive-messages-panel.tsx:36
- QueueManagerActor.receiveAndReply (cyclomatic 16) core/src/main/scala/org/elasticmq/actor/QueueManagerActor.scala:26
- generate-messages-modal.GenerateMessagesModal (cognitive 34) ui/components/generate-messages-modal.tsx:29
- send-message-modal.SendMessageModal (cognitive 29) ui/components/send-message-modal.tsx:32
- queue-details.QueueDetails (cognitive 25) ui/components/queue-details.tsx:22
- create-queue-modal.CreateQueueModal (cognitive 24) ui/components/create-queue-modal.tsx:12
- queue-list.QueueList (cognitive 20) ui/components/queue-list.tsx:14
- queue-details.ActionBtn (cognitive 19) ui/components/queue-details.tsx:283
- generate-messages-modal.GenerateMessagesModal::handleGenerate (cognitive 18) ui/components/generate-messages-modal.tsx:71
- Limits.verifyQueueName (cognitive 17) core/src/main/scala/org/elasticmq/Limits.scala:158
- TheSQSRestServerBuilder.start (cognitive 16) rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/SQSRestServerBuilder.scala:137
- queue-card.QueueCard (cognitive 16) ui/components/queue-card.tsx:16
- queue-card.CardBtn (cognitive 16) ui/components/queue-card.tsx:134
- receive-messages-panel.MessageCard (cognitive 16) ui/components/receive-messages-panel.tsx:36
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Change coupling: QueueActorMessageOps.scala ↔ QueueActorQueueOps.scala core/src/main/scala/org/elasticmq/actor/queue/QueueActorMessageOps.scala:1
- REDACTED
- REDACTED
- Off the main sequence: core
- Coverage not measured — JavaScript/TypeScript suite
- No DR/backup evidence
- Duplicated block (50 lines × 2 locations) ui/components/create-queue-modal.tsx:69
- Duplicated block (36 lines × 2 locations) ui/components/generate-messages-modal.tsx:130
- Duplicated block (26 lines × 2 locations) ui/components/generate-messages-modal.tsx:345
- Duplicated block (20 lines × 2 locations) ui/components/generate-messages-modal.tsx:302
- Duplicated block with local edits (20 matched lines × 2 locations) ui/components/queue-details.tsx:24
- Duplicated block (19 lines × 2 locations) ui/components/create-queue-modal.tsx:325
- Duplicated block (17 lines × 2 locations) ui/components/generate-messages-modal.tsx:8
- Duplicated block (14 lines × 3 locations) ui/components/create-queue-modal.tsx:274
- Duplicated block (14 lines × 2 locations) ui/components/generate-messages-modal.tsx:414
- Duplicated block (13 lines × 2 locations) ui/components/generate-messages-modal.tsx:37
- Duplicated block (7 lines × 2 locations) ui/components/generate-messages-modal.tsx:176
- Duplicated block with local edits (7 matched lines × 2 locations) ui/components/generate-messages-modal.tsx:59
- Duplicated block (5 lines × 2 locations) ui/components/generate-messages-modal.tsx:68
- Complex function GenerateMessagesModal (cyclomatic 33, cognitive 30) ui/components/generate-messages-modal.tsx:29
- Complex function SendMessageModal (cyclomatic 19, cognitive 17) ui/components/send-message-modal.tsx:32
- Complex function QueueDetails (cyclomatic 16, cognitive 15) ui/components/queue-details.tsx:22
- Complex function QueueList (cyclomatic 15, cognitive 14) ui/components/queue-list.tsx:14
- Complex function ReceiveMessagesPanel (cyclomatic 15, cognitive 12) ui/components/receive-messages-panel.tsx:219
- Complex function CreateQueueModal (cyclomatic 14, cognitive 12) ui/components/create-queue-modal.tsx:12
- Complex function sendMessage (cyclomatic 13, cognitive 16) REDACTED:103
- Complex function createQueue (cyclomatic 13, cognitive 13) REDACTED:244
- Complex function MessageCard (cyclomatic 13, cognitive 12) ui/components/receive-messages-panel.tsx:36
- Complex function CardBtn (cyclomatic 13, cognitive 10) ui/components/queue-card.tsx:134
- Complex function QueueCard (cyclomatic 12, cognitive 11) ui/components/queue-card.tsx:16
- ui/components/send-message-modal.tsx: 460 lines of code ui/components/send-message-modal.tsx:1
- ui/components/receive-messages-panel.tsx: 457 lines of code ui/components/receive-messages-panel.tsx:1
- ui/components/generate-messages-modal.tsx: 410 lines of code ui/components/generate-messages-modal.tsx:1
- Swallowed exception (empty catch) ui/components/queue-card.tsx:107
Minor — 52 finding(s)
- Orphaned file ui/components/receive-messages-panel.tsx:1
- Orphaned file ui/components/create-queue-modal.tsx:1
- Orphaned file core/src/main/scala/org/elasticmq/actor/queue/MessageQueue.scala:1
- Orphaned file REDACTED:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/QueueAttributesOps.scala:1
- Orphaned file ui/components/queue-card.tsx:1
- Orphaned file core/src/main/scala/org/elasticmq/Limits.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/actor/queue/operations/MoveMessagesAsyncOps.scala:1
- Orphaned file persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/SqlQueuePersistenceActor.scala:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/TagQueueDirectives.scala:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/ListMessageMoveTasksDirectives.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/actor/queue/operations/ReceiveMessageOps.scala:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/StartMessageMoveTaskDirectives.scala:1
- Orphaned file persistence/persistence-file/src/main/scala/org/elasticmq/persistence/file/QueueConfigUtil.scala:1
- Orphaned file persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/DBMessage.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/FifoDeduplicationIdsHistory.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/actor/QueueManagerMessageMoveOps.scala:1
- Orphaned file persistence/persistence-sql/src/main/scala/org/elasticmq/persistence/sql/MessageRepository.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/actor/queue/QueueActorStorage.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/metrics/MBeanMetrics.scala:1
- Orphaned file core/src/main/scala/org/elasticmq/actor/queue/ReceiveRequestAttemptCache.scala:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/ListDeadLetterSourceQueuesDirectives.scala:1
- Orphaned file persistence/persistence-file/src/main/scala/org/elasticmq/persistence/file/QueuePersister.scala:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/CancelMessageMoveTaskDirectives.scala:1
- Orphaned file rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/MessageAttributesSupport.scala:1
- REDACTED
- REDACTED
- REDACTED
- Most significant orphaned file ui/components/generate-messages-modal.tsx:1
- Most significant orphaned file ui/components/send-message-modal.tsx:1
- Off-boarding risk: anonymized user #1
- Further sole-owners (lower concentration)
- No ADRs found
- Projects may be oversized for their cohesion
- REDACTED
- Concentrated knowledge decay
- REDACTED
- REDACTED
- REDACTED
- No ADRs
- Logging is not universal
- No SAST
- No rollback/health safety
- No release approval gate
- No app-layer HTTPS enforcement detected
- No security response headers detected
- No inbound request validation detected
- Scala's null is not held to the type system everywhere
- Silent fallback default in catch ui/lib/theme-provider.tsx:19
Minor — 3 finding(s)
- Outdated: ch.qos.logback:logback-classic
- Outdated: com.amazonaws:aws-java-sdk-sqs
- Outdated: software.amazon.awssdk:sqs
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-08810785e26f438bb28e445827854c64/history.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-08810785e26f438bb28e445827854c64/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off --exclude *.arrow --exclude *.avro --exclude *.csv --exclude *.dat --exclude *.db --exclude *.feather --exclude *.geojson --exclude *.h5 --exclude *.hdf5 --exclude *.jsonl --exclude *.log --exclude *.ndjson --exclude *.npy --exclude *.npz --exclude *.orc --exclude *.parquet --exclude *.pickle --exclude *.pkl --exclude *.psv --exclude *.sqlite --exclude *.sqlite3 --exclude *.tfrecord --exclude *.tsv --exclude *.txt . | 49 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | trivy | — | trivy fs --scanners vuln --format json --quiet --severity CRITICAL,HIGH,MEDIUM,LOW --skip-dirs **/bin/** --skip-dirs **/obj/** . --skip-db-update | 17 | artifacts/raw/trivy-fs.json |
| D31 · IaC & Container Security | trivy | — | trivy config --format json --quiet . | 14 | artifacts/raw/trivy-config.json |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. semgrep could not parse 1 file(s) — `rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/BatchRequestsModule.scala` — so the PII/GDPR sweep did not cover them at all. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | trivy | — | trivy fs --scanners vuln --format json --quiet --severity CRITICAL,HIGH,MEDIUM,LOW --skip-dirs **/bin/** --skip-dirs **/obj/** . --skip-db-update | 0 | artifacts/raw/trivy-fs.json |