fix: Prevent nil pointer panic in monitor loop

[Attacktive]

The evaluateJob function was proceeding to process job events even when MachineGet was kind of unsuccessful; the exit code 404 alone is covered.

changes:

• added an explicit return when MachineGet returns an error (non-404).
• added a check if machine is nil even if no error is returned

[Attacktive]

I'm not 100% sure if it deliberately proceeds in non-404 cases, so let me know if it does. 🙂

[Copilot]

Pull request overview

This PR fixes a potential nil pointer dereference panic in the evaluateJob function by ensuring proper error handling when MachineGet fails and by adding a defensive nil check even when no error is returned.

Changes:

• Added early return when MachineGet returns a non-404 error to prevent further processing
• Added explicit nil check for the machine object before accessing its properties
• Restructured error handling logic to use if-else for better control flow

Comments suppressed due to low confidence (1)

internal/cron/monitor.go:79

• The error is being logged with both WithError(err) and %v formatting of the same error, which results in duplicate error information in the log output. Remove the : %v and err parameter from the format string to avoid redundancy.

				log.WithError(err).Errorf("failed to get machine %s: %v", job.MachineID.String, err)

---

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

[Copilot]

The error is being logged with both WithError(err) and %v formatting of the same error, which results in duplicate error information in the log output. Remove the : %v and err parameter from the format string to avoid redundancy.