UHK60v1=Reproducible freeze from activateKeyPostponed

[GrauLab]

Hi, I was able to distill a minimal config that reproduces the freezes from activateKeyPostponed:

• I started from the vanilla QWERTY keymap, and replaced each letter on the base row (a,s,d,f,g,h,j,k,l) with the same one-liner macro:
• This macro just contains the command activateKeyPostponed atLayer fn2 prepend $thisKeyId.
• On fn2, the corresponding keys are just mapped to their vanilla keystrokes in Agent.
• (An example config is attached [1], but you need to press LMod+LCase first to switch to the simple QWERTY test scenario.)

Expected behavior:

• No visible change relative to QWERTY typing.

Actual behavior:

• It works fine for some words, but then my UHK just freezes. (To get the freeze quickly, just slam the base row.)
• Sometimes the freeze occurs before sending the release event of a tap, causing OS key repetition.
• The only way out at this point seems to be power-cycling.

---

Background rationale/why this macro?:

• Imaging you have your own secondary resolver that decides to just play the primary vanilla action after all. With this activateKeyPostponed command you could implement the desired vanilla actions conveniently with Agent on fn2, and only need one elegant macro line for any trigger key. This can save quite some config space (relative to hard-coding and maintaining all vanilla keystrokes on macro level).
• From a more abstract but equivalent and maybe useful point of view, this is like a noConsume modifier for the macro trigger key: Imagine you would use this activateKeyPostponed prepend immediately as first line of your resolver macro in postponing mode. Then the resulting queue state should be identical to before calling the resolver, making the macro "transparent". Then your resolver just needs to toggleLayer primaryAction or toggleLayer secondaryAction before opening the postponer for precisely/just the first pending key press that triggered it. In this way, the key press would be "routed" to the right actions layer. And thanks to prepend, everything would be played automatically in the correct/incoming typing order...

Remarks (more like wild guesses...) for debugging:

• Could it be a race/sync/deadlock condition when updating/prepending to the postponer queue?
• I do not fully understand whether releases have their own queue entry. (I recall that I tried once, and was ultimately unable, to just open the postponer for playing pending releases while keeping new presses postponed for screening them in a resolver/lookahead loop first. So, I guess releases are not fully independent first class citizens of the postponer queue.) So, if releases are somehow "linked" to their presses in the queue, then prepending new keys might also need careful consistent updates of these link structures, especially if the same key is pressed again? But just a wild guess...

---

As always, thank you for your help and your great work with the macro language! And have nice weekend first. :)

[1] 20250803=one-liner on QWR reproducing the activateKeyPostponed freezes.json