Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix try_locate_tx_by_* functions #51

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jdziworski-bc
Copy link

No description provided.

@jdziworski-bc jdziworski-bc changed the title Increase try_locate_tx_by_incoming_message block search range Fix try_locate_tx_by_* functions Dec 14, 2023
@@ -671,12 +672,15 @@ async def try_locate_tx_by_incoming_message(self, source, destination, creation_

for shard_data in shards['shards']:
shardchain = shard_data['shard']
for b in range(3):
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3 was not enough for some cases and transaction wouldn't be found. Increased to 10.

Copy link
Collaborator

@dungeon-master-666 dungeon-master-666 Dec 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @jdziworski-bc, thank you for your PR. I think there are these points to consider:

  1. Usually the distance of blocks with out_tx and in_tx becomes > 3 when the network experiences a high load and the message queue contains many entries. In that case, the distance might be even greater than 10.
  2. Under high load the network splits into shards.
  3. Under high load lite servers are usually busy and response time increases significantly.

Let's say the network has 10 shards, for each shard we lookup + read transactions of 10 blocks. In total, it results in 200 requests to the lite server in the worst case. It is not the desired outcome in toncenter.com/api/v2 because it puts an additional load on liteservers.
As an option, I suggest adding the parameter scan_blocks_count with default value 3 and you can adjust it for your use case. Would it work for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants