[lesnik512]

The broker's access logger dropped the last character of every timer ID. TimersParamsStorage passed message_id_ln=-1 to FastStream's get_broker_logger, and FastStream's ExtendedFilter slices record.message_id[:message_id_ln]. A slice of [:-1] cuts the final character, so t-149 was logged as t-14 and t-3 as t-.

Found while running the Sentinel failover drills (#117). The drill handled 150 timers, t-0 to t-149, each exactly once, but the "Received" and "Processed" lines showed only 15 distinct IDs, 10 times each: t-, t-1 to t-9, and t-10 to t-14. Delivery was fine. The log context was correct too, and concurrent consumes do not leak context into each other. Only the formatting was wrong, but it made the logs useless for following a single timer during an incident.

The fix passes sys.maxsize, so IDs are never truncated, and drops the width from %(message_id)s in the format string. The old -1 read as "no limit" for both truncation and padding. I kept that intent and did not adopt FastStream's 10-character limit: timer IDs are user-chosen, often UUIDs, and a 10-character prefix would make different timers look alike in the logs.

tests/test_log_context.py publishes 12 timers with max_concurrent=4 and checks that the "Received" and "Processed" records name each timer ID exactly once. It failed before the fix with the truncated IDs.