Yes – the business logic is to get live data from our workflow execution while it is running – ideally we would be able to get a stream of the logs from the process using a query method. As for code, I have a snippet:
[within workflow class implementation]
private val singerActivities: SingerActivityInterface = Workflow
.newActivityStub(SingerActivityInterface::class.java,
ActivityOptions.newBuilder()
.setScheduleToCloseTimeout(Duration.ofDays(1)).build())
private val singerActivityCallback: SingerActivityCallBackInterface =
Workflow.newActivityStub(SingerActivityCallBackInterface::class
.java, ActivityOptions.newBuilder()
.setScheduleToCloseTimeout(Duration.ofDays(1))
.build())
............. [within Workflow method] ..................
singerResult = singerActivities.tapToTarget(singerConfig,
singerActivityCallback, singerResult)
Inside of the tapToTarget method, there are calls to a method to process the logs line-by-line and in each line, a method from singerActivityCallback is called. In practice, though, this causes a stack overflow error