Node reports “11 pending user deploys” that are always filtered.

[Timekiller7]

What did you expect to see?

When heartbeat is enabled, the node reports “11 pending user deploys”, I expected it to successfully propose a block that actually includes those deploys (or, if none are eligible yet, to not trigger proposing and avoid looping failures).

What did you see instead?

The node repeatedly tries to propose because of pending deploys, but then selects 0 deploys for the block (valid=0 … selected=0), effectively creating an empty block candidate and failing the propose with InternalDeployError that comes from Block validation failed with InvalidParents - proposal conditions no longer met, skipping propose. This repeats in a loop, and the node keeps trying to create block 2 over and over.

Steps to reproduce the bug

1. Run network of nodes (bootstrap, validator1, validator2, validator3)
2. Enable heartbeat for each validator (in our case: check-interval = 10 seconds, max-lfb-age = 30 seconds)
3. Observe validators' log

What version of RNode are you using?

Built image from c7d1cea.

Can be downloaded from docker hub: public.ecr.aws/f6y9h6x4/asi-chain/node:v0.1.2

[linear]

F1R-107

[nashef]

I'm investigating 11 user deploys, because I don't understand that either. However, these are just info/debug messages and not actually errors indicating a problem. I'm keeping this bug open as a marker, but changing the subject line to reflect the interesting bug.

See discord for fixing the heartbeat loop, which is a separate configuration issue in your environment.

[spreston8]

Analysis Summary

After reviewing both Scala and Rust integration test runs, the observed behavior is working as intended and all tests pass consistently.

What's happening

The "pending user deploys in storage" heartbeat loop between block inclusion and finalization is expected behavior given the current deploy pool lifecycle:

1. A deploy is submitted and enters the pool
2. The deploy is included in a proposed block (e.g., block Create GitHub Action to create and publish a F1r3fly release to GitHub's Maven repository and Docker registry #3)
3. The pool does not evict the deploy at inclusion time — it waits for finalization
4. During the ~50s window between inclusion and finalization, the heartbeat sees deploys in the pool but finds them alreadyInScope=N, selected=0 (already in a DAG ancestor)
5. This results in empty heartbeat blocks being proposed during that window
6. Once finalization occurs, the pool is cleaned and the loop stops

Outcome

• Scala: Empty heartbeat blocks succeed normally; finalization proceeds correctly
• Rust: Transient InvalidParents errors self-recover; all blocks finalize correctly
• All integration tests pass: Scala 34/34, Rust 33 passed / 1 skipped / 0 failed

Conclusion

The behavior is a known property of pool-keyed-to-finalization semantics rather than a bug. No changes are needed — the node self-corrects and tests pass reliably. Closing as resolved.