This change assumes all errors from publishBlock are app related failures.

If we bubble up all the errors up from publishBlock and panic, it's also going to panic on when maxPendingHeaders reaches its limit which is not an app failure. We should NOT panic on this.

Ok, I'll update the non error as warning logs and return without an error.
IMHO, we should only return an error if we need to stop

🛠️ Refactor suggestion

Loop exits on single publish error

Returning the error here causes the entire lazy loop to stop after a single failed publishBlock.
If the goal is “halt at app failure” but still tolerate transient DA/network errors, consider distinguishing between fatal and retryable errors, e.g.:

if err := m.produceBlock(...); err != nil {
    if errors.Is(err, coreexecutor.ErrAppError) { // fatal
        return err     // bubble & panic
    }
    m.logger.Error("transient publish error", "err", err)
    continue          // retry on next tick
}

🛠️ Refactor suggestion

⚠️ Potential issue

Guard against context.Canceled and avoid a potential sender-block on errCh

1. trySyncNextBlock returns ctx.Err() when the node is shutting down.
   Forwarding a plain context.Canceled into errCh forces the whole node into the error branch even though this is an expected shutdown path.

2. errCh is created with capacity 1. If another goroutine already sent an error that hasn’t been drained yet, this send will block forever, freezing the sync goroutine.

A defensive pattern is:

-if err = m.trySyncNextBlock(ctx, daHeight); err != nil {
-    errCh <- fmt.Errorf("failed to sync next block: %w", err)
-    return
-}
+if err = m.trySyncNextBlock(ctx, daHeight); err != nil &&
+   !errors.Is(err, context.Canceled) {
+    select {
+    case errCh <- fmt.Errorf("failed to sync next block: %w", err):
+    default: // channel already holds an error – don’t block
+    }
+    return
+}

You’ll need to add errors to the import list.

In block/sync.go around lines 65 to 68, the current code sends errors including
context.Canceled directly to errCh, which causes unnecessary error handling on
expected shutdowns and can block if errCh is full. Modify the code to check if
the error is context.Canceled and skip sending it to errCh in that case. Also,
use a non-blocking send to errCh by selecting on errCh and a default case to
avoid blocking if errCh is already full. Add the "errors" package to imports to
use errors.Is for error comparison.

🛠️ Refactor suggestion

Replicate the shutdown-friendly panic filter here as well

Mirror the context.Canceled guard suggested for the header branch to keep behaviour consistent.

-if err != nil {
-    panic(fmt.Errorf("failed to sync next block: %w", err))
-}
+if err != nil && !errors.Is(err, context.Canceled) {
+    panic(fmt.Errorf("failed to sync next block: %w", err))
+}

In block/sync.go around lines 114 to 117, the panic on error from
trySyncNextBlock should be guarded against context.Canceled errors to allow
graceful shutdown. Modify the error handling to check if the error is
context.Canceled and skip panicking in that case, mirroring the
shutdown-friendly panic filter used in the header branch. This ensures
consistent behavior during shutdown scenarios.