We used fast.com to speed test our new office internet connection and the next day got an irate email from corporate (who had argued we didn't need the new connection) about "watching Netflix all day". I imagine some C-level thought they had a real gotcha! moment until I showed them the site.
> Depending on how your code is written, modifying code baked into workflows becomes complex, as anything that modifies the history event ordering breaks determinism in already-deployed workers.
I see this as Temporal surfacing inherent complexity of the domain in a way that forces the developer to consider it, rather than introducing extra complexity.
If it didn't make workflow determinism a strict requirement, the requirement would still exist - it would just hurt much worse in production when it's broken.
Actually Temporal does have a way to avoid determinism called rainbow deployments.
If you're fine with deploying several versions of workers (and are on a reasonably new version) you can just avoid the determinism issue altogether with their k8s controller.
If you do need to have some long workflows, there is an explicit hook for "what happens to existing workflows on version upgrade".
But to be fair - none of the other orchastrators I used (like AirFlow) made me write workflows.IsNewCode/IsOldCode like temporal does. On the other hand AirFlow doesn't even have the capability to do that in the first place (or at least it didn't last I used it).
Well sure - that's essentially the same as wrapping the whole workflow in a version check for each version; copy-paste the whole lot and change the code wherever. It's still surfacing an issue that would otherwise be less visible on a system that did allow a worker on a new version to pull an old half-completed workflow
It's ok to force-push a branch that only you have worked on (and even in the case of others working on the same branch it can be fine as long as you communicate with them)
This is something you have to generally handle manually since absorb won't squash hunks with ambiguous targets, but I typically stack these branches and accept the dependency. I have had instances where this has backfired a little bit re: ordering but thankfully with JJ and the very patient little man in my computer named Codex it's easy to reorder them and end up with the same diff
The mega merge wouldn't handle that based on the way the article shows. You COULD have a revset that includes stacked changes, though. That does work and is what I currently do.
Where E stacks on C and D stacks atop A. In the case above, A-E are revsets of either 1 or more commits. JJ doesn't care if they are or not. You'd generally bookmark the revset on the final "commit" as the pointer.
/ features/add-widgets
/ / features/add-widget-integration
/ A - D \
-- B ----- - Megamerge
\ C - E /
\ \ feature/add-new-page
\ feature/rework-navigation
In the example above, let's say you rework the navigation. You could have it exist alongside the navigation rework, but changes are you don't want to do the work twice. You just say "hey, this depends on the nav rework" and so it's there inside of the repo.
The thing is there is another way to do this where you end up with 4 different parents in a megamerge and your nav rework touches the megamerge and your new page is yet another revset is just a fork off of it. But yeah... JJ gives you a lot of flexibility in this manner.
This is true but I don't think the downvotes are "fake" though. There's just a whole lot of people who truly believe they are Making the World a Better Place Through Capitalism
Maybe this is just a symptom of my screen addiction, but I keep a close eye on this site for a lot of the day. I’ve noticed a pattern where my commments initially get one or two upvotes (within the first 5-10 minutes of posting) but will then immediately get a greater than or equal amount of downvotes very quickly. It happens consistently enough that I’ve noticed a pattern. The upvotes happen sporadically and the downvotes happen simultaneously.
reply