You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently added additional trustlines to our accounts and hit the hardcoded limit of 15 assets in pathfinding requests. This resulted in breaking things on our end.
fmt.Errorf("list of assets exceeds maximum length of %d", handler.MaxPathLength),
use the wrong variable. It should be handler.MaxAssetsParamLength instead of handler.MaxPathLength
It is possible to omit the above max asset validation check by submitting a source_account or destination_account instead of a list of assets. This is not a good substitute however as the pathfinder then behaves differently (and takes the balance of the source account into consideration in strict-receive requests). Also, the validation check for max assets is probably in place for a reason (e.g. vs cpu flooding?) so this could be a potential exploit.
The text was updated successfully, but these errors were encountered:
What problem does your feature solve?
We recently added additional trustlines to our accounts and hit the hardcoded limit of 15 assets in pathfinding requests. This resulted in breaking things on our end.
What would you like to see?
Is it possible to make
go/services/horizon/internal/httpx/router.go
Line 29 in b147bca
What alternatives are there?
We'd have to refactor a whole lot of our code base to iterate over pathfinding requests.
Other observations (bug reports)?
The error messages in
go/services/horizon/internal/actions/path.go
Line 134 in d550cca
go/services/horizon/internal/actions/path.go
Line 294 in d550cca
handler.MaxAssetsParamLength
instead ofhandler.MaxPathLength
It is possible to omit the above max asset validation check by submitting a source_account or destination_account instead of a list of assets. This is not a good substitute however as the pathfinder then behaves differently (and takes the balance of the source account into consideration in strict-receive requests). Also, the validation check for max assets is probably in place for a reason (e.g. vs cpu flooding?) so this could be a potential exploit.
The text was updated successfully, but these errors were encountered: