Skip to content

fix: start postman listeners from latest in local env #2371

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.

Sign up for GitHub

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

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

fix: start postman listeners from latest in local env #2371

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bc66009
fix: start postman listeners from latest in local env
Othryades Feb 12, 2026
83b2e6a
Merge branch 'main' into chore/fix-e2e-bridge-token-1247
Othryades Feb 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 8 additions & 10 deletions docker/config/postman/env
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,10 @@ L1_CONTRACT_ADDRESS=0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9
# WARNING=FOR LOCAL DEV ONLY - DO NOT REUSE THESE KEYS ELSEWHERE
L1_SIGNER_PRIVATE_KEY=0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba
L1_LISTENER_INTERVAL=2000
# Starting block for L1 event fetching. Controls from which block the Postman service starts fetching events.
# Options: -1 = current latest block (default), 0 = from genesis (all historical events),
# specific number = custom starting block (e.g., 18500000)
# Note: This value is always prioritized when set, even if database contains previously processed messages
L1_LISTENER_INITIAL_FROM_BLOCK=0
# Starting block for L1 event fetching.
# -1 = start from latest block (fast local e2e/default)
# 0 = replay from genesis (historical backfill, slower startup)
L1_LISTENER_INITIAL_FROM_BLOCK=-1
Copy link
Contributor

@jonesho jonesho Feb 13, 2026

Choose a reason for hiding this comment

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

@Othryades I'm keen on setting this to -1, but do you see it really helps the timeout issue? Set to -1 can speed up the event fetching, but iiuc, the impact could be quite miminal given the fresh L1 chain without too many blocks, same for L2_LISTENER_INITIAL_FROM_BLOCK

Copy link
Contributor

@VGau VGau Feb 13, 2026

Choose a reason for hiding this comment

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

@Othryades We can put -1 but it won't fix the issue in the e2e tests because this param is useful when we restart the postman.
We always use a fresh local stack and the postman only start once so this change won't have any effect.

L1_LISTENER_BLOCK_CONFIRMATION=1
L1_MAX_BLOCKS_TO_FETCH_LOGS=1000
L1_MAX_GAS_FEE_ENFORCED=true
Expand All @@ -16,11 +15,10 @@ L2_CONTRACT_ADDRESS=0xe537D669CA013d86EBeF1D64e40fC74CADC91987
# WARNING=FOR LOCAL DEV ONLY - DO NOT REUSE THESE KEYS ELSEWHERE
L2_SIGNER_PRIVATE_KEY=0xfcf854e0a0bc6fd7e97d7050e61a362c915cecd6767a32267b22e8b7af572e58
L2_LISTENER_INTERVAL=2000
# Starting block for L2 event fetching. Controls from which block the Postman service starts fetching events.
# Options: -1 = current latest block (default), 0 = from genesis (all historical events),
# specific number = custom starting block (e.g., 1000000)
# Note: This value is always prioritized when set, even if database contains previously processed messages
L2_LISTENER_INITIAL_FROM_BLOCK=0
# Starting block for L2 event fetching.
# -1 = start from latest block (fast local e2e/default)
# 0 = replay from genesis (historical backfill, slower startup)
L2_LISTENER_INITIAL_FROM_BLOCK=-1
L2_LISTENER_BLOCK_CONFIRMATION=0 # set confirmation as zero since L2 block won't auto increase
L2_MAX_BLOCKS_TO_FETCH_LOGS=1000
L2_MAX_GAS_FEE_ENFORCED=false
Expand Down
Loading