bug: proposal delay not working?

[bonustrack]

I've created a proposal on a space having 5mn delay, but somehow the proposal was active directly after creating it, see here: http://localhost:8080/#/sn-sep:0x03ffa8d9c48aa1208569af37292c9b0408496859803c9b7245172844e0c33745/proposal/2 http://localhost:8080/#/sn-sep:0x03ffa8d9c48aa1208569af37292c9b0408496859803c9b7245172844e0c33745/settings

I was able to cast a vote before 5mn, this sound like issue may be at the contract level?

@pscott

[Sekhmet]

Looking at the event.

Start timestamp is 1718792993000 Wed Jun 19 2024 12:29:53 GMT+0200 (Central European Summer Time) so UI seems to use what was broadcast.

Block time is 19 June 2024 at 12:24:53 CEST so it was +5 minutes of delay.

[Sekhmet]

Timestamps at API are different for created (1718792938000) vs start (1718792993000) - 55s difference.

I'm not sure how info::get_block_timestamp() works for yet unconfirmed transactions.

If blocks happen at 12:00, 12:05, 12:10 etc. and I send transaction at 12:09 what will be get_block_timestamp?

It looks like it would get timestamp of 12:05, instead of timestamp in the future, giving us this behaviour where optimistically indexed transactions could have start timestamp lower than created timestamp (for example when there is no voting delay). Looks like this proposal got affected: https://testnet.snapshotx.xyz/#/sn-sep:0x01c63c00ce530de98ff6469bef06271231bc8a82ffc4122f9ec3ada7de23d68a/proposal/3

[pscott]

@Sekhmet @bonustrack after double checking with Mirko from the Pathfinder team (Starknet node), they confirmed that the get_block_timestamp() syscall will refer to the "last" block timestamp. In your example @Sekhmet this would indeed be 10:05.

This means that having a voting_delay smaller than the time it takes to create a block will indeed have no effects. I don't think it's a big issue (voting_delay should be ~ hours or days imho), but let me know if you think otherwise.