-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[Feature Request]: Prism Support for Timer and ProcessingTime #31177
Comments
I generally just want to be able to test timers locally with any runner, not too picky. the file I am trying to run
|
I found this capability description, but I dont see prism here/elsewhere and have no idea if I need to file against prism somewhere else |
Likely duplicate of #30083 |
Thank you for filing this issue! Processing Time is presently in Progress for prism, so this is a duplicate. Getting time right turns out to be tricky, so it's taken longer than desired to complete. You're right, follow #30083 for current progress, and #30492 for the current WIP PR for getting test execution working (before actually hooking in a real clock). #29650 is the current umbrella tracker for Prism. That'll eventually be migrated to the capabilities page. There's a goal for the next release (2.57.0) to have prism binaries produced as part of the release, so that 2.58.0 can add easy access to Prism in the Java and Python (and typescript and swift and rust?) SDKs. I'll close this issue once I've understand the full request and make sure your expectations and our plans are properly aligned. |
Basic "test focused" ProcessingTime handling is merged in with #30492. Unfortunately due to other tasks I had to focus on, I didn't manage to get the real time clock handling in yet. But the current set up should be sufficient for "unit test" execution. Processing time timers won't auto fail the pipeline with 2.57.0, but they also won't wait around for the real time to occur. They will be processed in the correct order with the correct restrictions though (only one scheduled per key per timer per window per tag etc...). Unbounded SplittableDoFns (with ProcessContinuations) don't currently schedule into the processing time system just yet, but that's also going to be worked on with adding "real time". Using a TestStream as an input into the pipeline will allow control over the synthetic processing time clock, and will hopefully be sufficient to test things out with some semblance of ordering. Triggers remain unimplemented, so ProcessingTime triggers remain a failure case for such pipelines. |
closing since this is completed! |
What would you like to happen?
I want to be able to test timers on the prism runner in GoLang.
Issue Priority
Priority: 2 (default / most feature requests should be filed as P2)
Issue Components
The text was updated successfully, but these errors were encountered: