You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fluss.apache.org by "tridev-tej (via GitHub)" <gi...@apache.org> on 2026/10/12 03:53:41 UTC

[PR] Add blog on tracing job retries with Apache Fluss [fluss-blog]

tridev-tej opened a new pull request, #22:
URL: https://github.com/apache/fluss-blog/pull/22

   Added a retry walkthrough with captured histories, recovery diagrams and a public lab package
   
   Historical results are preserved; current portable setup remains unverified
   
   Related #20
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Add blog on tracing job retries with Apache Fluss [fluss-blog]

Posted by "polyzos (via GitHub)" <gi...@apache.org>.
polyzos commented on PR #22:
URL: https://github.com/apache/fluss-blog/pull/22#issuecomment-6164023171

   @tridev-tej can you rebase?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Crash-safe retries with Apache Fluss [fluss-blog]

Posted by "polyzos (via GitHub)" <gi...@apache.org>.
polyzos commented on PR #22:
URL: https://github.com/apache/fluss-blog/pull/22#issuecomment-6309822697

   @tridev-tej merged 🫡


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Crash-safe retries with Apache Fluss [fluss-blog]

Posted by "polyzos (via GitHub)" <gi...@apache.org>.
polyzos merged PR #22:
URL: https://github.com/apache/fluss-blog/pull/22


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Crash-safe retries with Apache Fluss [fluss-blog]

Posted by "tridev-tej (via GitHub)" <gi...@apache.org>.
tridev-tej commented on PR #22:
URL: https://github.com/apache/fluss-blog/pull/22#issuecomment-6291716772

   hi @polyzos, addressed your feedback and pushed the updated post.
   Could you take another look and let me know if it's ready to publish?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Add blog on tracing job retries with Apache Fluss [fluss-blog]

Posted by "polyzos (via GitHub)" <gi...@apache.org>.
polyzos commented on PR #22:
URL: https://github.com/apache/fluss-blog/pull/22#issuecomment-6261860861

   Hi @tridev-tej, thank you for this contribution, and for the care you put into it. The experiment is thoughtful. Showing that the B1 and B2 crashes leave *identical* Fluss histories, so recovery has to ask the downstream service, is a great insight, and the full pattern (persist intent, keep the action ID stable, look up the receipt, hold when unsure) is exactly right. I learned from reading it.
   
   I'd like to suggest a revision pass before we publish, mostly so the post lands better with readers of the Fluss blog.
   
   **1. Show more of what Fluss brings.**
   At the moment, most of the post would work the same with any append-only log, and readers here will likely ask "why Fluss?" Some places where Fluss could shine:
   - Line 158 sets `table.log.ttl=0ms` and notes that keeping events indefinitely "requires a storage plan." Fluss's lakehouse tiering is that plan, and it fits the story naturally.
   - Line 156 leaves duplicate `event_id` rows to the reducer. A Primary Key Table keyed on `event_id`, or a PK table holding current job state next to the log, would be a nice Fluss-native answer.
   - A short example of querying the traces, for example with Flink SQL, would deliver on the "tracing" in the title.
   
   **2. Consider the title and framing.**
   The post is really about crash-safe retries for side-effecting workers, so a title along those lines might fit better. Also, the LLM framing is currently half-present. Either drop it, or lean in fully ("durable execution for AI agents"), which is a very timely angle that suits your background.
   
   **3. Lead with the insights; gather the caveats in one place.**
   The careful scoping is appreciated, but caveats in almost every paragraph make the main points harder to find. I'd suggest one "Limitations" section near the end and lighter prose elsewhere. For example, the environment details and the historical command in lines 50–58 could move to an appendix or the repo README. Line 136 could open with the finding ("a restarted worker sees the same history in both cases") and leave the normalization method for a footnote.
   
   **4. Simplify the reproduction material.**
   I'd suggest moving the lab into a GitHub repo of your own, with a simple `docker compose` quickstart, and linking to it from the post, instead of adding the `static/labs/` folder to the website. The current `public-package/REPRODUCE.md` (loop devices, `mkfs.ext4`, `sudo`, pinned Docker versions) would be hard for readers to follow. As an Apache project, we also try not to host archives or scripts on the site that aren't official releases.
   
   **5. A few code points, since readers tend to copy snippets.**
   - `FlussStore.append` creates a new `Table`, writer and admin lookup for each event. A long-lived writer would be a better example to copy.
   - All jobs share one bucket, recovery scans from offset 0, and `scanTo` requires *all* writers to be stopped. It's worth saying clearly that this design is serial-only, and maybe briefly sketching how it would scale (per-job bucketing, or a PK table for state).
   - `acks=all` with a single replica behaves like `acks=1`, so a short note would avoid confusion.
   - For the high-watermark semantics (line 81), links to user docs or the client Javadoc would suit readers better than server internals like `Replica.java`.
   
   **Minor**
   - The crash-windows diagram is excellent and might make a stronger cover image than the current one.
   - The output screenshot might read better as a small table of the B2 events than as raw JSON with SHA hashes.
   - Line 144, about not trusting an arbitrary API's 404, is a great practical point that deserves a bit more space.
   
   Thanks again for this. The core work is strong, and with some reshaping I think this will be a really valuable post. Happy to help review the next iteration or talk through any of these points - or even make a few changes and ask your thoughts.
   
   Let me know your thoughts.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Add blog on tracing job retries with Apache Fluss [fluss-blog]

Posted by "tridev-tej (via GitHub)" <gi...@apache.org>.
tridev-tej commented on PR #22:
URL: https://github.com/apache/fluss-blog/pull/22#issuecomment-6123679241

   hi @polyzos added the article from #20 here
   could you take a look
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Add blog on tracing job retries with Apache Fluss [fluss-blog]

Posted by "tridev-tej (via GitHub)" <gi...@apache.org>.
tridev-tej commented on PR #22:
URL: https://github.com/apache/fluss-blog/pull/22#issuecomment-6255902035

   hi @polyzos rebase done
   [Check Blog](https://github.com/apache/fluss-blog/actions/runs/38565264575) is waiting for maintainer approval - could you approve the run and review the article?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org