A recurring failure was tied to a tracker item, the ticket has since been closed, and the failure is back on this run. What does ReportPortal's stored link, and an Allure 3 `resolutions` rule, each still do to that failure?

## Two artefacts, one blind spot Both mechanisms in question - ReportPortal's stored ticket link and an Allure 3 `resolutions` rule - answer "does this failure already have a ticket?" without ever asking the tracker. Neither is wired to the tracker's lifecycle. Closing the ticket is an event in a system that has no channel back into either artefact, so the honest answer to "what changed when the ticket closed?" is **nothing at all**. ## ReportPortal: six fields, none of them a state A stored link is an `ExternalSystemIssue` with exactly six fields - `ticketId`, `submitDate`, `btsUrl`, `btsProject`, `url` and `pluginName`. There is no status, no resolution, no close date. The server can fetch an item's current summary and state through the configured plugin when somebody opens the screen, but that is a live read whose answer is never written back into the stored entry. So on the run where the failure returns, the failure is labelled exactly as it was: same defect type, same link, same `submitDate` from months ago. There is a second-order effect that makes this worse rather than merely stale. When ReportPortal reuses an earlier verdict for a newly arrived failure - the mechanism that spares a human from re-triaging the same red every run - it copies the ticket set from that earlier decision onto the new failure's issue wholesale. One stale link therefore does not sit still; it reproduces onto each new occurrence on its own, and each new occurrence then looks freshly, confidently linked. ## Allure 3: the rule re-matches, it does not re-check An Allure 3 `resolutions` rule is a matcher plus a category. On every run the rule is evaluated against that run's own failed and broken results, and if the message still matches `messageRegexp`, or the identity is still in `testCaseId`, the rule fires again. Nothing in that evaluation consults a tracker, and there is no expiry field on a rule. What the rule then does depends on its category, and this is the distinction that decides whether the returning failure stays visible: | resolution | effect on the returning failure | |---|---| | `issue` | attaches the tracker link; the failure still counts as a failure | | `muted` | the failure is treated as ignored and dropped from the gate's view | | `accepted` | the failure is treated as ignored and dropped from the gate's view | That table is the practical answer. A failure resolved as `issue` is annotated but not hidden - it still lands in the failure counts a quality gate evaluates. A failure resolved as `muted` or `accepted` is filtered out before those rules ever see it. So a stale `muted` rule from a ticket closed months ago will hold a genuinely new regression out of the build's verdict, and the run comes back green while the report shows the test red with a comment explaining why it was fine to ignore. ## Why nobody notices Three properties conspire: - **The suppression is silent by design.** Its whole purpose was to stop a known failure being noisy, so it produces no output when it works. - **The matchers are broader than intended.** `messageRegexp` is a search rather than a whole-string match, so a rule written for one failure absorbs any later failure whose message merely contains the phrase. A new bug with a similar message inherits the old ticket's suppression. - **A rule that stops matching is equally silent.** When the failure is genuinely fixed, the rule simply matches nothing. Nothing warns that a rule has gone idle, so a config accumulates dead rules that are indistinguishable from live ones by inspection. ## What actually helps Neither product will tell you; the check has to be one you build and run on a schedule of your own: 1. **Enumerate outward, not inward.** Collect the distinct `ticketId` values currently attached across the project, ask the tracker for their states in one query, and report the ones already closed. `btsUrl`, `btsProject` and `pluginName` on each link are what let you route that query correctly. 2. **Diff the written baseline.** In Allure 3, `known-issues.json` records which failures were sitting under which issue id on a given run. Diffing it between runs shows a ticket quietly acquiring failures it was never about. 3. **Make suppressions expire, not persist.** Both `muted` and `accepted` require a `comment`; put a date and an owner in it, and treat an undated suppression as a defect at review time. A rule with a review date is the only version of this that degrades safely, because the artefact itself will never tell you it has gone stale.