Restart closed queues

[viktorerlingsson]

WHAT is this pull request doing?

This adds functionality to restart closed queues/streams.

Adds:

• Restart method for queues/streams
• API endpoint
• UI button
• lavinmqctl cmd
• specs

Fixes #1290

HOW can this pull request be tested?

Run the new specs

[claude]

Claude finished @viktorerlingsson's task —— View job

---

Code Review Complete

I've reviewed the PR for bugs, security vulnerabilities, performance issues, missing error handling, and Crystal anti-patterns.

Issues Found:

1. Missing Return Type Annotation (src/lavinmq/amqp/queue/queue.cr:208)

• The restart! method should have an explicit return type annotation : Bool to ensure type safety
• Without it, changes to the start method could break the return contract expected by HTTP controller

2. Potential State Inconsistency (src/lavinmq/amqp/queue/queue.cr:222)

• The reset_queue_state method always sets @state = QueueState::Running, but should preserve paused state
• If a queue was paused before closing, it should return to paused state after restart, not running
• The paused state handling is done in start but gets overridden by the unconditional reset

3. Missing Error Context (src/lavinmq/http/controller/queues.cr:124)

• The error message "Queue was not restarted" provides no information about why the restart failed
• Could be improved to indicate the queue was already running or provide more specific context

Todo List:

• Read and analyze queue restart implementation
• Check stream restart implementation
• Review HTTP controller changes
• Analyze CLI tool changes
• Review UI changes
• Check test coverage and implementation
• Report findings

The implementation is generally solid with good test coverage. The restart functionality correctly handles message store recreation and channel reinitialization. No security vulnerabilities or performance issues identified.

---

[carlhoerberg]

Are the claude code review comments valid?

[viktorerlingsson]

Are the claude code review comments valid?

Some of them where, some not! I've addressed the ones I think was relevant

[snichme]

I do feel that this feature is valuable to have I'm just concerned if doing adds more complexity to the queue code that will be hard to handle in the future.

[snichme]

I feel that we already have a lot of state to keep track of, while this doesn't add more states it adds more places where we need to keep track of all the states for a queue.
Not sure if there is a better solution for this at the moment. I just wanted to flag that the more state changes we add to more difficult it will be to keep everything in correct state.

[viktorerlingsson]

Yeah, there is a lot to keep track of. I guess another option would be to delete the queue object in VHost and recreate it, but I think that just moves the complexity to VHost instead.

[snichme]

Did another round on this, found some more things to consider

[snichme]

restart! is a no-up, just returns when the queue is running ( unless @closed)

Maybe recover would be a better name?

And also, have a response that say that the queue was restarted/recovered so you dont issue a PUT to this endpoint and you get nothing back but also nothing happens with the queue.

[viktorerlingsson]

Yeah , I took inspiration from pause! / resume!. But we can make it a little smarter so the user can know what happens.

[snichme]

I write the initial implementation on pause and resume, so even I should learn from my own comments.
But that is for another PR :)