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 -
"...sponsorship actions may be performed on layer 2 using the ownership or management proxies regardless of the dominion status...".
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.
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.