fix: machine behavior in cases of input reject or exception

[vfusco]

No description provided.

[Copilot]

Pull Request Overview

This PR fixes the behavior of the Advance function to return an empty hash when inputs are rejected or result in exceptions, instead of attempting to validate and copy hash data that isn't meaningful in these scenarios.

• Modified Advance to only process outputs hash when the input is accepted
• Updated test assertions to verify empty hash is returned for non-accepted cases
• Added logging for successful input processing completion
• Enhanced Makefile with targets for reject-dapp and exception-dapp test applications

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
pkg/machine/implementation.go	Conditionally validates and copies outputs hash only when input is accepted
pkg/machine/implementation_test.go	Updated test expectations to verify empty hash for rejection and exception cases
internal/advancer/advancer.go	Added info logging after successful input processing
Makefile	Added reject-dapp and exception-dapp targets, fixed echo-dapp comment

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[endersonmaia]

While we don't have proper metrics support, I think we could at least log the duration it took to process each input in the logs.

Untested code:

diff --git a/internal/advancer/advancer.go b/internal/advancer/advancer.go
index f5538521..14a22886 100644
--- a/internal/advancer/advancer.go
+++ b/internal/advancer/advancer.go
@@ -11,6 +11,7 @@ import (
        "os"
        "path"
        "strings"
+       "time"
 
        "github.com/cartesi/rollups-node/internal/config"
        "github.com/cartesi/rollups-node/internal/inspect"
@@ -206,6 +207,9 @@ func (s *Service) processInputs(ctx context.Context, app *Application, inputs []
                        return err
                }
 
+               // Register when input started to be processed
+               start := time.Now()
+
                s.Logger.Info("Processing input",
                        "application", app.Name,
                        "epoch", input.EpochIndex,
@@ -236,6 +240,9 @@ func (s *Service) processInputs(ctx context.Context, app *Application, inputs []
                        return err
                }
 
+               // Calculate elapsed time processing input
+               duration := time.Since(start).Milliseconds()
+
                s.Logger.Info("Processing input finished",
                        "application", app.Name,
                        "epoch", input.EpochIndex,
@@ -243,6 +250,7 @@ func (s *Service) processInputs(ctx context.Context, app *Application, inputs []
                        "status", result.Status,
                        "outputs", len(result.Outputs),
                        "reports", len(result.Reports),
+                       "duration_ms", duration,
                )
 
                // Store the result in the database

[guidanoli]

For context, such measure would be to benchmark an app's capacity to process inputs given the base-layer data availability throughput. I do think it can be a useful metric to have available on the reference node logs, so that we don't have to do arithmetic with log timestamps.

[vfusco]

@endersonmaia please open a issue for this. And we have a draft branch for metrics support that we still need to work on