Feat/issue 412 tyre c codes

[Ragha02]

No description provided.

[Ragha02]

feat: implement Pirelli C-Code compound mapping (fixes #412)

Description
This PR addresses issue #412 by dynamically mapping the relative F1 tyre compounds (SOFT, MEDIUM, HARD) to their exact Pirelli C-Codes (C1-C5) based on the specific Grand Prix allocation.

Architecture & Approach
To avoid breaking changes, API schema regressions, or requiring a retroactive MongoDB data migration for historical livetiming data, I implemented this feature purely at the API Egress layer:

Added a new util/tyre_allocation.py module to hold the static MEETING_KEY_ALLOCATIONS mappings.
Intercepted the MongoDB payload within services/query_api/app.py when collection == "stints".
Mutated the egress dictionary to append a new compound_c_code field on the fly before caching and returning the response.

This approach is 100% backwards compatible.
If the meeting_key allocation is not yet mapped in the dictionary, compound_c_code safely defaults to null.

[br-g]

Hello @Ragha02,

Thank you so much for this contribution and for taking the initiative to address issue #412! We really appreciate your time and effort, especially as a first-time contributor to the project.

While mapping the relative F1 tyre compounds to their exact Pirelli C-Codes is a requested feature, the current implementation using static mappings in util/tyre_allocation.py would require a lot of regular manual hardcoding for every new Grand Prix. To minimize maintenance overhead, that is not the current direction of the project.

We are definitely interested in this feature, but it would need to be handled through an automated or fully dynamic upstream approach rather than static egress-layer mutations. Let us know if you are open to exploring a different architectural approach for this!

[Ragha02]

Hello @Ragha02,

Thank you so much for this contribution and for taking the initiative to address issue #412! We really appreciate your time and effort, especially as a first-time contributor to the project.

While mapping the relative F1 tyre compounds to their exact Pirelli C-Codes is a requested feature, the current implementation using static mappings in util/tyre_allocation.py would require a lot of regular manual hardcoding for every new Grand Prix. To minimize maintenance overhead, that is not the current direction of the project.

We are definitely interested in this feature, but it would need to be handled through an automated or fully dynamic upstream approach rather than static egress-layer mutations. Let us know if you are open to exploring a different architectural approach for this!

Hello,

Thank you so much for the feedback! That completely makes sense. I agree that maintaining a static dictionary every race weekend would become a nightmare for maintenance, and an automated upstream approach is the right architectural direction.

I am definitely open to exploring a dynamic approach! My current thought process is that we could extract the C-compound allocation directly from the raw upstream F1 Live Timing feed (e.g., by parsing the SessionInfo payload or the relevant signalR messages broadcasted at the start of the weekend) to dynamically map SOFT, MEDIUM, and HARD to their respective C-Codes at runtime. ILL BE Looking more into it , before i put my final draft

Thanks again for the guidance!