Rust bindings for libtcod 1.6.3 (the Doryen library/roguelike toolkit)
A Dwarf Fortress/Rimworld-like game written in Rust
Rust library providing a lazily filled Cell
A paste tool written entirely in Rust, and powered by nickel.rs.
Rust bindings for the Wolfram|Alpha web API
A bot for Discord, written in Rust using the serenity-rs library.
A python script to automate the installation of my preferred minecraft setup.
Rust bindings for the XKCD web API
A TCOD back-end for the Piston game engine
Netflix Conductor client for Rust
started time in 18 days
Hmm. Interesting. That's a good question. Sounds like there's a hole in my theory. I'll investigate deeper.
comment created time in 19 days
Another C#/XNA game I am working on.
fork in 22 days
started time in 23 days
I have a custom
WorkflowArchiverModule that searches for workflows to archive with
IndexDAO::searchArchivableWorkflows and then archives them with
What this should do is remove the workflow from redis and mark it as
archived: true in ES.
Usually this works fine.
Sometimes, this process fails, and the workflow is removed from redis but not marked as
archived: true in ES. I believe this happens when ES puts the indices into a
read_only_allow_delete state if we're hitting high disk usage watermarks.
To mitigate this, I'm going to avoid running the workflow archiver if our ES indices are in a read-only state, but I was wondering how to recover from this failure when ES comes back online?
If a workflow is stuck in this state and ES comes back to read/write, then the next time the workflow archiver runs it'll get that workflow from
ExecutionDAO::removeWorkflow(workflowId, true) will fail with:
287211533 [workflow-archiver-0] ERROR com.netflix.conductor.core.orchestration.ExecutionDAOFacade - No such workflow found by id: 50049693-2e5c-4ce9-9007-ed33c9830b78 287211533 [workflow-archiver-0] WARN com.cpaas.platform.WorkflowArchiverModule$WorkflowArchiver - Error archiving workflow: 50049693-2e5c-4ce9-9007-ed33c9830b78 com.netflix.conductor.core.execution.ApplicationException: BACKEND_ERROR - Error removing workflow: 50049693-2e5c-4ce9-9007-ed33c9830b78 at com.netflix.conductor.core.orchestration.ExecutionDAOFacade.removeWorkflow(ExecutionDAOFacade.java:204) at com.netflix.conductor.service.ExecutionService.removeWorkflow(ExecutionService.java:342) at com.cpaas.platform.WorkflowArchiverModule$WorkflowArchiver.archiveWorkflow(WorkflowArchiverModule.java:132) at com.cpaas.platform.WorkflowArchiverModule$WorkflowArchiver.searchAndArchiveWorkflows(WorkflowArchiverModule.java:117) at com.cpaas.platform.WorkflowArchiverModule$WorkflowArchiver.lambda$init$0(WorkflowArchiverModule.java:92) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: com.netflix.conductor.core.execution.ApplicationException: No such workflow found by id: 50049693-2e5c-4ce9-9007-ed33c9830b78 at com.netflix.conductor.core.orchestration.ExecutionDAOFacade.getWorkflowById(ExecutionDAOFacade.java:80) at com.netflix.conductor.core.orchestration.ExecutionDAOFacade.removeWorkflow(ExecutionDAOFacade.java:182)
Is there a way to mark this workflow as
archived: true from within a conductor-server module, skipping the redis deletion? If not, could we perhaps add that functionality?
created time in a month
I seem to be observing the same behaviour as well. @s50600822 do you know what caused it?
comment created time in a month