Job A, assigned with Credential A, the trigger is cron every 5 minutes
Job B, assigned with Credential B, the trigger is “Flow” trigger of Job A
I’ve tried this in the platform, it works correctly, the Job B (which got triggered by the success of Job A) has Credential B in state.configuration (because Job A got assigned Credential A, and Job B got assigned Credential B)
But, if using the Microservice (I exported the project.yaml config and applied it to the microservice), the Job B always got the Credential A as its initial state.configuration because of the “Flow” trigger.
How did you discover this issue? Was there an error thrown when the Job B started to run? Or did you seen in the Job B run logs that it was trying to connect with the wrong Credential A system?
@Levi , thanks for pointing this out—possible that there’s a bug there. Also, we’ve stopped development on Microservice and Lightning, even though it’s in alpha, has actually already surpassed it. Are you up for connecting with @amber so she can help you get set up on Lightning?
Hi @aleksa-krolls, okay, thank you for the support on this.
Yes, there is an error thrown when the Job B runs which when I read through, it said it was trying to connect using credential A.
I also saw the Job B run logs, then get inside the OpenFn/Microservice container and see the initial state file (state-${EPOCH}-${RANDOM_STRING}.json) used inline with the expression for Job B, and it has configuration object the same value as configuration object in the initial state file for Job A.
I have verified a bug in engine (the backend library that we use in microservice and lightning) that would result in the previous jobs credential being added to the state instead of the job that is about to be triggered.
Oh, I wanted to mention - since microservice development has pretty much stopped (your issue here did warrant an exception to that status ), with that the changes to engine since the last release of microservice are fairly significant.
So while we do have plenty of tests, and CI gave us the go ahead, this was a very quick release so let us know if you encounter any show stoppers - I can’t guarantee how long we will support microservice.
I did have to upgrade the version of elixir and nodejs in microservice, 1.11 to 1.13 and 14.18 to 16.15 respectively. Node modules are now always installed in priv/openfn, and I would advise against changing that path.
Internally we’ve changed how we install adaptors, namely we only support npm modules now; this means two things:
Adaptor names must be full npm module names: e.g. @openfn/language-salesforce@2.10.0
Make sure your a required adaptor/version is available npm. (You can check with npm view @openfn/language-salesforce for example). Or head to https://www.npmjs.com/package/@openfn/language-postgresql (replacing the adaptor name with the one you are checking).
@stu When using the new version of microservice:v.0.4.0, the container exited with code 0 when running docker-compose up
I was using a hacky workaround for microservice:v0.3.3, that is to use the same credential for the 2 jobs but modified the key-value pairs, with the configuration related to Job B added the prefix something like “job_b_” (i.e. “job_b_access_token”)
Hey @Levi , exiting with code 0 sounds like something related to the docker-compose file or even the dockerfile itself, rather than the application. I think Stu mentioned this but microservice isn’t under active development—the only FOSS funding we have right now is earmarked for Lightning.
Did you have an active microservice deployment that was impacted by this upgrade, or were you just testing it out?
), with that the changes to 
