indeedeng / indeedeng/iwf

Support get (up to) N or all messages from channel in one command

Open
#301 2 comments 0 reactions 0 assignees View on GitHub
1st enhancement feature important in-review medium
Dominant language
Go
Stars
661
Forks
63
PR merge metrics
No merged PRs in 30d

Description

### Problem and Use case
A good use case -- kicking off N number states running in parallel, but also want to wait for them to complete.
So each state will publish a message to a channel to tell it's completed. Now if we also want to wait for something else, e.g. a timer for reminder, then it will be quite tricky to wait for One timer OR N messages.

Ideally, it should be just using a single command for N messages:
```
public CommandRequest waitUntil( Integer numOfWaits...){
return CommandRequest.forAnyComandCompleted(
TimerCommand.create(...),
InternalChannelCommand.create( ChannelName, numOfWaits)
);
}
```

But today it needs to use N commands with anyCommandCombination:
```
public CommandRequest waitUntil( Integer numOfWaits...){
return CommandRequest.forAnyComandCombinationCompleted(
CommandCombination.create( ["timerCmdId"], ["msg1CmdId", "msg2CmdId, ...],
TimerCommand.create("timerCmdId", ...),
InternalChannelCommand.create("msg1CmdId", ChannelName ),
InternalChannelCommand.create("msg2CmdId", ChannelName )
...
);
}
```
Or using array:
```
List commandList = new ArrayList()
commandList.add(TimerCommand.create("timerCmdId", ...));
List commandIdList = new ArrayList();
commandIdList.add("timerCmdId");
for(i=0;i

Contributor guide

Open the contributing guide

Research direction

Start with service/interpreter/workflowImpl.go around line 618 and trace how repeated channel commands consume messages. Review the CommandRequest and InternalChannelCommand paths to define the behavior for OneToAll, ZeroToAll, and a fixed N. Done means the requested messages are consumed atomically rather than partially consumed before waiting.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, java
Domain
backend-api-design, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.