fix(decay-rules): exclusion rule upsert recomputes valid_until on every re-ingestion, bypassing the score-unchanged guard

[ericWadeFord]

Description

PR #15525 (shipped in 7.260422.0) added a short-circuit to the indicator upsert path that skips decay recomputation when the incoming score matches the stored score. The guard resolves #15476 for indicators using the classic decay rule, but it does not cover indicators with a decay exclusion rule. For excluded indicators, the upsert path continues to recompute valid_until and flip is_detected on every re-ingestion cycle, even when nothing about the indicator has changed.

The editField (UI) path already has the correct early-return for excluded indicators. The upsert path does not. The guards are asymmetric.

Environment

• OpenCTI version: 7.260510.0 (includes the fix from Playbook action overrides decay exclusion rule #15476 / PR [backend] Upsert indicator: skip decay computation if no score change (#15476) #15525)
• Affected scope: indicators with a decay exclusion rule applied
• Unaffected scope: indicators using the classic decay rule (correctly handled by PR [backend] Upsert indicator: skip decay computation if no score change (#15476) #15525)

Steps to Reproduce

1. Configure an external feed (e.g. a TAXII or stream connector) that ingests indicators on a recurring playbook cycle.
2. Apply a decay rule with an exclusion predicate so that matching indicators bypass classic decay (expected valid_until set far in the future by the source).
3. Let the playbook re-ingest the same indicator on its next cycle with an unchanged score.
4. Inspect the indicator history.

Expected Behavior

The upsert short-circuit added by PR #15525 fires: valid_until and is_detected are left untouched when the incoming score equals the stored score. Excluded indicators should behave at least as conservatively as classic-decay indicators — ideally more so, since exclusion is an explicit opt-out of decay recomputation.

Actual Behavior

On every re-ingestion cycle, the AUTOMATION MANAGER user overwrites valid_until with a decay-computed date and flips is_detected from No to Yes. If the source then re-asserts the original values on its own cycle, the field flaps back. In observed cases, consecutive AUTOMATION MANAGER overwrites occur with identical scores (down to the same timestamp on the incoming bundle), confirming the score-unchanged guard from PR #15525 is never reached on this code path.

[nino-filigran]

Can you please share the playbook that causes the issue?

I need to assess this at multiple level:

• playbook acts as an admin, meaning that often it can bypasses things. Therefore, the first point ot assess is if the safeguard applies also on playbook on classic decay rules.
• if it applies, then I'll restest it against exclusion rules.

The rational behind the safe guard was to avoid mutliple changes, to avoid score recomputation all the time, causing performance issues. On decay exclusion rules, changing the valid until does not cause any performance issue (in theory at least), so we can argue whether this behavior is needed.

In theory, you could reduce the confidence level of your feed to avoid such behavior. Because if you exclude it from decay, it means that it needs to maintained by external sources (or that it should not decay).
Additionnally, please be aware that we have an ongoing issue with Playbooks & IOC that is happening, which might also cuase issues for you here. https://github.com/OpenCTI-Platform/opencti/[issue](https://github.com/OpenCTI-Platform/opencti/issues/16365)s/16365So I'll wait that this one gets resolved first, to fully assess this one.

[ericWadeFord]

Here you go

20260604_playbook_EF Test.json

[nino-filigran]

@ericWadeFord reproduced on our side & as you can see PR in progress.