CFE-4681: default timer_policy => reset for classes: promises (3.28.0) by nickanderson · Pull Request #6174 · cfengine/core

nickanderson · 2026-06-11T17:26:27Z

Summary

Flips the default timer_policy for classes: promises from absolute to reset for 3.28.0.

#6167 introduced the timer_policy attribute on classes: promises with a default of absolute (preserve) for backward compatibility. This PR changes that default to reset so that:

classes: promises align with classes bodies, whose timer_policy has always defaulted to reset.
A persistent class that keeps being rediscovered keeps persisting, rather than lapsing once its original timer expires — matching what most users expect.

Setting timer_policy => "absolute" explicitly restores the previous skip-and-preserve behavior.

⚠️ Stacked on #6167 — merge that first

This branch is based on CFE-4681/timer-policy-classes-promises (the #6167 head), so until #6167 merges to master this PR's diff shows both. The change unique to this PR is the final commit, 07657cce4.

⚠️ Master-only — do NOT backport

The timer_policy attribute is being backported to the LTS streams (3.27.2, 3.24.5) with the long-standing absolute default preserved, so behavior on those releases is unchanged and reset stays opt-in there. This default flip is intentional for 3.28.0 only.

Changes

GetContextConstraints() (attributes.c): resolve the timer policy to RESET by default; only an explicit timer_policy => "absolute" selects PRESERVE.
ExpandDeRefPromise() (promises.c): an already-defined persistent class is no longer skipped unless timer_policy => "absolute" is set, so the default reset can refresh the timer.
mod_common.c: syntax doc default for the classes: promise timer_policy updated to reset.
Acceptance test persistent_timer_policy_default.cf: a classes: promise with no timer_policy resets the timer on a subsequent run.

Test plan

libpromises compiles clean (full-binary link blocked locally by an unrelated ASan toolchain issue; relying on CI for the binary build + acceptance run)
CI acceptance tests pass, including the existing persistent_timer_policy.cf (explicit absolute → still skipped) and the new persistent_timer_policy_default.cf (default → reset)

Ticket: CFE-4681

…ntSave ValueSizeDB() was called with strlen(key), but WriteDB(), ReadDB() and DeleteDB() store and look up keys with strlen(key) + 1 (including the terminating NUL), and LMDB matches keys by exact byte length. The lookup therefore never found the stored record and always reported size 0. Passing strlen(key) + 1 makes the lookup match the key as written. This lets EvalContextHeapPersistentSave() find an existing record and act on it: preserve an already-set, unexpired timer (CONTEXT_STATE_POLICY_PRESERVE) and log "Resetting" rather than "Creating" on a RESET save. Ticket: CFE-4681 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

nickanderson · 2026-06-11T18:52:44Z

@cf-bottom jenkins please

cf-bottom · 2026-06-11T18:57:28Z

Alright, I triggered a build:

Jenkins: https://ci.cfengine.com/job/pr-pipeline/13944/

Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-13944/

Add a timer_policy attribute to classes: promises, controlling whether a persistent class timer resets on re-evaluation ("reset") or preserves the original expiry ("absolute"). Defaults to "absolute" for backward compatibility; planned to change to "reset" in 3.28.0 to match classes bodies, keeping "absolute" on the 3.24 and 3.27 LTS backports. timer_policy without persistence is now an error, since it only governs the persistence timer. Ticket: CFE-4681 Changelog: Title Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CFE-4681 added a timer_policy attribute to classes: promises with the default "absolute" (preserve) for backward compatibility. For 3.28.0 the default becomes "reset", aligning classes: promises with classes bodies (whose timer_policy has always defaulted to reset) and matching the common expectation that a persistent class which keeps being rediscovered should keep persisting rather than lapsing. - GetContextConstraints(): default the resolved timer policy to RESET; only an explicit timer_policy => "absolute" selects PRESERVE. - ExpandDeRefPromise(): an already-defined persistent class is no longer skipped unless timer_policy => "absolute" is set, so the default reset can refresh the timer. - Update the classes: promise syntax doc default to "reset". - Acceptance test persistent_timer_policy_default.cf: a classes: promise with no timer_policy resets the timer on a subsequent run. This is a master-only change. The timer_policy attribute itself is being backported to the 3.27.x and 3.24.x LTS streams (3.27.2, 3.24.5) with the long-standing "absolute" default preserved, so behavior there is unchanged and reset remains opt-in. Ticket: CFE-4681 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

nickanderson · 2026-06-12T19:46:42Z

@cf-bottom jenkins please

cf-bottom · 2026-06-12T19:52:40Z

Alright, I triggered a build:

Jenkins: https://ci.cfengine.com/job/pr-pipeline/13948/

Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-13948/

craigcomstock

Really the only thing I think is "required" to change is adding Changelog to the last commit which changes the default timer_policy for classes promises to reset.

craigcomstock · 2026-06-15T14:58:03Z

    // first see if we have an existing record, and if we should bother to update
    {
-        int existing_info_size = ValueSizeDB(dbp, key, strlen(key));
+        int existing_info_size = ValueSizeDB(dbp, key, strlen(key) + 1);


Seems like we should avoid having to provide a +1 to a parameter and maybe fix the ValueSizeDB() function instead somehow. Maybe a wrapper function for lookup that normalizes the information so code is easier to write/read?

Yeah maybe, but probably in some other pr.

craigcomstock · 2026-06-15T15:02:18Z

    {
        const char *tp = PromiseGetConstraintAsRval(pp, "timer_policy", RVAL_TYPE_SCALAR);
-        if (StringEqual(tp, "reset"))
+        if (StringEqual(tp, "absolute"))


I see no Changelog in this "Changed default timer_policy for classes: promises to reset" commit. Better fix that I think.

craigcomstock · 2026-06-15T15:05:57Z

+bundle agent check
+{
+  classes:
+      "first_ok" expression => regline(".*Creating persistent class.*timer_default_test_class.*",


Relying on a log message seems brittle. Do you have references here and in the code where the message lies to leave a breadcrumb trail for future code/test changes?

Maybe it would be better to investigate the LMDB database and check timestamps there? That would check the "truth" at the "source" right?

nickanderson mentioned this pull request Jun 11, 2026

CFE-4681: document timer_policy attribute on classes: promises cfengine/documentation#3682

Open

nickanderson and others added 2 commits June 12, 2026 13:34

nickanderson force-pushed the CFE-4681/default-reset-master branch from 07657cc to c5ab252 Compare June 12, 2026 18:38

nickanderson mentioned this pull request Jun 12, 2026

CFE-4681: timer_policy support for classes: promises #6167

Merged

5 tasks

craigcomstock requested changes Jun 15, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CFE-4681: default timer_policy => reset for classes: promises (3.28.0)#6174

CFE-4681: default timer_policy => reset for classes: promises (3.28.0)#6174
nickanderson wants to merge 3 commits into
cfengine:masterfrom
nickanderson:CFE-4681/default-reset-master

nickanderson commented Jun 11, 2026 •

edited by atlassian Bot

Loading

Uh oh!

nickanderson commented Jun 11, 2026

Uh oh!

cf-bottom commented Jun 11, 2026

Uh oh!

nickanderson commented Jun 12, 2026

Uh oh!

cf-bottom commented Jun 12, 2026

Uh oh!

craigcomstock left a comment

Uh oh!

craigcomstock Jun 15, 2026

Uh oh!

nickanderson Jun 15, 2026

Uh oh!

craigcomstock Jun 15, 2026

Uh oh!

craigcomstock Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Conversation

nickanderson commented Jun 11, 2026 • edited by atlassian Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

⚠️ Stacked on #6167 — merge that first

⚠️ Master-only — do NOT backport

Changes

Test plan

Uh oh!

nickanderson commented Jun 11, 2026

Uh oh!

cf-bottom commented Jun 11, 2026

Uh oh!

nickanderson commented Jun 12, 2026

Uh oh!

cf-bottom commented Jun 12, 2026

Uh oh!

craigcomstock left a comment

Choose a reason for hiding this comment

Uh oh!

craigcomstock Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

nickanderson Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

craigcomstock Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

craigcomstock Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

nickanderson commented Jun 11, 2026 •

edited by atlassian Bot

Loading