Refactor handlers

[xepozz]

Q	A
Is bugfix?	❌
New feature?	❌
Breaks BC?	✔️

Drop support pre-configured handlers, make it compatible with validator/hydrator handlers way

The old way:

1. Add handler name => handler definition mapping to config/params
2. Add handler name to the message getHandlerName method

The new way:

1. Create a class that implements the new MessageHandlerInterface
2. Add the class name to the message getHandler method

The new way is similar with validator's or hydrator's way.

[what-the-diff[bot]]

PR Summary

• Refactoring Message Handling
  • The PR changes the terminology from handlerName to handler in different classes and files for consistency. It affects the classes: Message, Queue, TestMiddleware, and various test files. This also includes renaming the method getHandlerName method to getHandler in the MessageInterface interface.
• Alteration in FileDownloader and Worker Classes
  • The handle method in the FileDownloader class will now output a MessageInterface object. Also, the same method in the Worker class will now throw a RuntimeException if the handler name is not found, increasing error handling.
• Removing handlers Property and QueueWorker Class
  • The handlers property has been removed from the Worker class constructor, and the QueueWorker class has been removed from di.php file, simplifying the structure.
• Addition of MessageHandlerInterface Interface
  • A new MessageHandlerInterface interface was added, which is implemented by the FakeHandler class, promoting code reusability and abstraction.
• Modification in MessageConsumingTest and MiddlewareTest Classes
  • MessageConsumingTest and MiddlewareTest now use different classes as the handler for messages (StackMessageHandler and NullMessageHandler respectively), which promotes diverse handling processes.
• Adding New Classes
  • Three new classes: ExceptionMessageHandler, NullMessageHandler, and StackMessageHandler were added, enhancing the system's capabilities to handle diverse message types.
• Removal of getMessageHandlers Method
  • The getMessageHandlers method was removed from TestCase class, reducing redundancy in the codebase.
• Additional Changes in Multiple Test Methods
  • Several test methods in files like MiddlewareDispatcherTest.php, QueueTest.php, SynchronousAdapterTest.php, and WorkerTest.php were modified, promoting better and diverse testing with modified handler values.

Minor changes and adjustments were made throughout the codebase to align with these changes. Please ask if further clarification is needed.

[codecov[bot]]

Codecov Report

Attention: 12 lines in your changes are missing coverage. Please review.

Comparison is base (5339df8) 83.98% compared to head (725ef84) 83.15%.

Files	Patch %	Lines
src/Worker/Worker.php	36.36%	7 Missing :warning:
config/di.php	0.00%	5 Missing :warning:

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #182      +/-   ##
============================================
- Coverage     83.98%   83.15%   -0.84%     
+ Complexity      359      345      -14     
============================================
  Files            46       46              
  Lines          1049     1021      -28     
============================================
- Hits            881      849      -32     
- Misses          168      172       +4     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[xepozz]

The idea was that handler is not a PHP class string because worker could be implemented in non-PHP.

Already discussed in the internal chat.

There're should be routing outside a message to be able to work with different services across the one queue.

[samdark]

With queue backends such as Redis, there's no external routing.

[samdark]

Discussed internally. It makes sense if we'll introduce "message type decorator" and "message-based handlers" for messages in a separate PR.