Fix incorrect sponsor displayed for L1 ships after escape #1116
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Removed use of 'azimuth.getPoint()' and instead using roller data to fetch additional details regardless of dominion. This is because 'azimuth.getPoint()' will show stale sponsor data for any L1 ship that has been adopted using an L2 transaction.
pkova
approved these changes
Sep 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There’s a bug in the OS section where an incorrect sponsor will be displayed for an L1 ship that has escaped to a new point (if the adoption transaction has been done using Bridge/L2).
For context, Bridge currently seems to only use L2 to execute the adopt transaction even if the sponsee is on L1 and the escape request is through L1. This is valid behaviour as per the docs -
Because of this, when using
getPoint()in azimuth-js, the returned values for ‘sponsor’, ‘escapeRequested’, and ‘escapeRequestedTo’ fields may not be accurate.This fix removes the condition that checks whether the point is L1 or L2, and instead only uses the roller to fetch additional details about the point.
Note that there’s still a try-catch fallback which uses azimuth-js if the initial call to the roller fails. I’ve left this in place for now but it arguably should also be removed.