refactor(streaming): retrieve epoch from task local storage

[BugenZhao]

Signed-off-by: Bugen Zhao [email protected]I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Epoch changes periodically in streaming executors, while providing a correct value is crucial to several components like LruCache, StateTable, PROCTIME(). For the simplicity of the interface design, we do not pass the value everywhere. Instead, we make these components to hold other copies of the value and let the executor call update_epoch when it needs to be updated.

This could be really error-prone if we accidentally forget to call that! For example, in #9459 we find that a lot of executors forget to update the epoch for the LRU cache, so the eviction will be problematic implicitly.

In this PR we attempt to provide the epoch in the task-local storage. Components can directly call curr_epoch to get the current epoch without any context, as long as it's in the scope of a running executor. We've also refactored the PROCTIME (#9088) to retrieve the epoch from this value.

This could be further used by LruCache and StateTable in the future.

NOTE: Per offline discussions, we agree that we should be really cautious and think twice before introducing such "global variables". Abusing it will hurt the maintainability of our system.

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

• I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

• My PR DOES NOT contain user-facing changes.

Click here for Documentation

Types of user-facing changes

Please keep the types that apply to your changes, and remove the others.

• Installation and deployment
• Connector (sources & sinks)
• SQL commands, functions, and operators
• RisingWave cluster configuration changes
• Other (please specify in the release note below)

Release note

[codecov]

Codecov Report

Merging #9488 (26a950f) into main (002b2f2) will decrease coverage by 0.01%.
The diff coverage is 54.71%.

@@            Coverage Diff             @@
##             main    #9488      +/-   ##
==========================================
- Coverage   70.73%   70.73%   -0.01%     
==========================================
  Files        1231     1232       +1     
  Lines      205371   205375       +4     
==========================================
- Hits       145275   145269       -6     
- Misses      60096    60106      +10     

Flag	Coverage Δ
rust	70.73% <54.71%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/expr/src/expr/mod.rs	60.78% <ø> (-4.74%)	⬇️
src/stream/src/executor/mod.rs	50.95% <ø> (ø)
src/stream/src/executor/wrapper.rs	0.00% <0.00%> (ø)
src/stream/src/executor/wrapper/epoch_provide.rs	0.00% <0.00%> (ø)
src/common/src/util/epoch.rs	85.84% <60.00%> (-4.27%)	⬇️
src/stream/src/executor/project.rs	87.50% <75.00%> (-0.23%)	⬇️
src/expr/src/expr/expr_proctime.rs	72.91% <94.44%> (+10.41%)	⬆️

... and 6 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more