feat: add jobs #688

atrauzzi · 2025-03-15T22:49:10Z

Description

Added initial support for jobs.

Issue reference

Closes: #667

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

Code compiles correctly
Created/updated tests
Extended the documentation

WhitWaldo · 2025-03-16T17:58:49Z

@atrauzzi This runs a linter (for now) as part of the build pipeline and failures will stop the build. Would you mind fixing the lint errors locally and pushing a commit with those changes as well so we can run the checks?

WhitWaldo

Excellent start - still a bit to go, but it's a good foundation.

src/interfaces/Client/IClientJobs.ts

WhitWaldo · 2025-03-17T21:55:24Z

src/interfaces/Server/IServerJobs.ts

+import { TypeDaprJobsCallback } from "../../types/DaprJobsCallback.type";
+
+export default interface IServerJobs {
+  listen(jobName: string, callback: TypeDaprJobsCallback): void;


Same here - I don't know that the server will ever pass along a job invocation without a payload (e.g. though of course it might be empty).

See above 🙂

WhitWaldo · 2025-03-17T21:57:04Z

src/types/jobs/JobSchedule.type.ts

+
+type EveryPeriod = `@every ${string}`;
+
+// note: This can get crazy, more than TS can really handle.


You might consider taking a look at how I built this out in the .NET SDK to accommodate each variation.

Most importantly - there are different sets of arguments that need to be provided based on this schedule and the other arguments used.

Mind elaborating on the different sets of arguments? I expanded things a fair bit in a recent push, maybe you wanna look at that and if you want, we can discuss here or in discord 🙂

src/types/jobs/CronExpression.type.ts

WhitWaldo

Coming along - note about the regexps though

src/types/jobs/CronExpression.type.ts

WhitWaldo

More thoughts

src/interfaces/Client/IClientJobs.ts

WhitWaldo · 2025-03-22T19:36:24Z

src/interfaces/Client/IClientJobs.ts

@@ -11,17 +11,17 @@ See the License for the specific language governing permissions and
 limitations under the License.
 */

-import { JobSchedule } from "../../types/jobs/JobSchedule.type";
+import { Schedule } from "../../types/jobs/JobSchedule.type";


Especially if the file only contains a single type, the type name should match the file name.

Yep, agreed.

WhitWaldo · 2025-03-22T19:38:03Z

src/interfaces/Server/IServerJobs.ts

-  listen(jobName: string, callback: TypeDaprJobsCallback): void;
-
-  listen<DataType>(jobName: string, callback: TypeDaprJobsCallback<DataType>): void;
+  listen(jobName: string, callback: (data: any) => unknown): void;


Why does this return an unknown? While the callback needn't necessarily return anything, the SDK does need to know that it was handled without error so it can send back a 200 OK.

That's the callback that users provide. I mark it as unknown so that it can be optionally sync or async.

Should we be imposing some kind of contract for the implementation to return, or just assume handling was successful if no exception is thrown?

test/e2e/jobs/jobs.test.ts

- Addresses - dapr#688 (comment) - dapr#688 (comment) Signed-off-by: Alexander Trauzzi <[email protected]>

ConstantinChirila · 2025-03-26T12:37:45Z

src/types/jobs/CronExpression.type.ts

+export type SecondOrMinute = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59;
+export type Hour = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23;
+export type DayOfMonth = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31;
+export type DayOfWeekNumber = 0 | 1 | 2 | 3 | 4 | 5 | 6;
+export type MonthNumber = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12;


This is a bit of a NIT, but theres a different way of adding type for these situations, which ive used before.
You would have first a type that would help you build such types:

type BuildNumberRange<T extends number, U extends number, R extends number[] = []> = R['length'] extends U ? R[number] : BuildNumberRange<T, U, [...R, R['length'] & number]>;

And then you can have your types like this:

export type SecondOrMinute = BuildNumberRange<0, 59> export type Hour = BuildNumberRange<0, 23> export type DayOfMonth = BuildNumberRange<1, 31> export type DayOfWeekNumber = BuildNumberRange<0, 6> export type MonthNumber = BuildNumberRange<1, 12>

Just an idea. I realise the BuildNumberRange type is quite hard to reason with for new comers, but its the type of "set it and forget it".

That's pretty slick.

joebowbeer · 2025-04-19T00:46:46Z

== APP ==     Error: 14 UNAVAILABLE: connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:50001: connect: connection refused"
== APP ==         at callErrorFromStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/call.ts:82:17)
== APP ==         at Object.onReceiveStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client.ts:360:55)
== APP ==         at Object.onReceiveStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client-interceptors.ts:458:34)
== APP ==         at Object.onReceiveStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client-interceptors.ts:419:48)
== APP ==         at /home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/resolving-call.ts:163:24
== APP ==         at processTicksAndRejections (node:internal/process/task_queues:78:11)
== APP ==     for call at
== APP ==         at ServiceClientImpl.makeUnaryRequest (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client.ts:325:42)
== APP ==         at ServiceClientImpl.invokeService (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/make-client.ts:189:15)
== APP ==         at /home/runner/work/js-sdk/js-sdk/src/implementation/Client/GRPCClient/invoker.ts:64:14
== APP ==         at new Promise (<anonymous>)
== APP ==         at GRPCClientInvoker.invoke (/home/runner/work/js-sdk/js-sdk/src/implementation/Client/GRPCClient/invoker.ts:63:12)
== APP ==         at Object.<anonymous> (/home/runner/work/js-sdk/js-sdk/test/e2e/grpc/server.test.ts:78:21) {
== APP ==       code: 14,
== APP ==       details: 'connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:50001: connect: connection refused"',
== APP ==       metadata: Metadata {
== APP ==         internalRepr: Map(2) { 'traceparent' => [Array], 'grpc-trace-bin' => [Array] },
== APP ==         options: {}
== APP ==       }
== APP ==     }
== APP == 
== APP ==       at Object.<anonymous> (test/e2e/grpc/server.test.ts:81:17)

WhitWaldo · 2025-04-19T10:15:12Z

== APP ==     Error: 14 UNAVAILABLE: connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:50001: connect: connection refused"
== APP ==         at callErrorFromStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/call.ts:82:17)
== APP ==         at Object.onReceiveStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client.ts:360:55)
== APP ==         at Object.onReceiveStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client-interceptors.ts:458:34)
== APP ==         at Object.onReceiveStatus (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client-interceptors.ts:419:48)
== APP ==         at /home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/resolving-call.ts:163:24
== APP ==         at processTicksAndRejections (node:internal/process/task_queues:78:11)
== APP ==     for call at
== APP ==         at ServiceClientImpl.makeUnaryRequest (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/client.ts:325:42)
== APP ==         at ServiceClientImpl.invokeService (/home/runner/work/js-sdk/js-sdk/node_modules/@grpc/grpc-js/src/make-client.ts:189:15)
== APP ==         at /home/runner/work/js-sdk/js-sdk/src/implementation/Client/GRPCClient/invoker.ts:64:14
== APP ==         at new Promise (<anonymous>)
== APP ==         at GRPCClientInvoker.invoke (/home/runner/work/js-sdk/js-sdk/src/implementation/Client/GRPCClient/invoker.ts:63:12)
== APP ==         at Object.<anonymous> (/home/runner/work/js-sdk/js-sdk/test/e2e/grpc/server.test.ts:78:21) {
== APP ==       code: 14,
== APP ==       details: 'connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:50001: connect: connection refused"',
== APP ==       metadata: Metadata {
== APP ==         internalRepr: Map(2) { 'traceparent' => [Array], 'grpc-trace-bin' => [Array] },
== APP ==         options: {}
== APP ==       }
== APP ==     }
== APP == 
== APP ==       at Object.<anonymous> (test/e2e/grpc/server.test.ts:81:17)

What's this in reference to?

joebowbeer · 2025-04-19T10:51:49Z

What's this in reference to?

@WhitWaldo This is the failure from the test run of the previous commit.

However, I don't think it sheds much light. I think the interesting failure is in the scheduler's (Testcontainer) log:

"failed to invoke schedule app job:
  error returned from app channel while sending triggered job to app:
    Post \"http://127.0.0.1:8070/job/test\": EOF"

I suspect this 127.0.0.1 is wrong.

test/e2e/jobs/jobs.test.ts

atrauzzi · 2025-04-24T17:30:07Z

Alright, so a small bit of progress on connectivity between the dapr daemon and the scheduler, but sadly not quite there with things yet.

I'm now running into a timeout scenario where it seems like any attempt to use the client.

dapr-js-sdk testcontainers jest timeout.txt

The code seems to hang when I try to create the job. @WhitWaldo, maybe you can spot something?

test/e2e/jobs/jobs.test.ts

joebowbeer · 2025-05-12T06:53:10Z

test/e2e/jobs/jobs.test.ts

+        .withTmpFs({
+          "/data": "rw",
+        })
+        // note: Because dapr containers don't have `sh` or `bash` inside, this is kind of the best health check.


Two comments:

Wait.forHttp(path, port) works for me, and is what Dapr's Testcontainer for Java does:

https://github.com/dapr/java-sdk/blob/ab8e41111de17ea5bc47b9d94dbab6fe30577590/testcontainers-dapr/src/main/java/io/dapr/testcontainers/DaprContainer.java#L60

The timeout should be much longer, e.g., 120_000

I suggest something like the following for the wait strategy

.withWaitStrategy(Wait.forHttp("/v1.0/healthz/outbound", DAPRD_HTTP_PORT) .forStatusCodeMatching((statusCode) => statusCode >= 200 && statusCode <= 399)) .withStartupTimeout(120_000)

This has proven to be the trickiest, but also avoidable if I stick with my prior approach, waiting for console output. For some reason that endpoint never seems to ready up.

test/e2e/jobs/jobs.test.ts

codecov · 2025-07-12T05:43:32Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (d1bf38a) to head (74a3f99).
Report is 31 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #688   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines            6         6           
  Branches         1         1           
=========================================
  Hits             6         6

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Signed-off-by: Alexander Trauzzi <[email protected]>

(...make Jack a dull boy) Signed-off-by: Alexander Trauzzi <[email protected]>

Signed-off-by: Alexander Trauzzi <[email protected]>

- Addresses - dapr#688 (comment) - dapr#688 (comment) Signed-off-by: Alexander Trauzzi <[email protected]>

* Removing prettifier from the build pipeline as it's an unnecessary step during a build operation. * Version number updated in package-lock.json Signed-off-by: Whit Waldo <[email protected]> Signed-off-by: Alexander Trauzzi <[email protected]>

Removed references to Workflow components and replaced with "dapr" for the name in the HTTP client. Signed-off-by: Whit Waldo <[email protected]> Signed-off-by: Alexander Trauzzi <[email protected]>

Removes stale bot + adds me to repo owners for bot actions Signed-off-by: Whit Waldo <[email protected]> Signed-off-by: Alexander Trauzzi <[email protected]>

Signed-off-by: Alexander Trauzzi <[email protected]>

Signed-off-by: Joe Bowbeer <[email protected]> Signed-off-by: Alexander Trauzzi <[email protected]>

Signed-off-by: Alexander Trauzzi <[email protected]>

Signed-off-by: Alexander Trauzzi <[email protected]> # Conflicts: # package-lock.json

Signed-off-by: Alexander Trauzzi <[email protected]>

WhitWaldo

Just want to make sure we've got strong test coverage - reviewed on GitHub, so I can't run a check myself, but if it looks good to you, I'm satisifed.

Also, please remove the gRPC implementations of the Jobs bits. The way I see it, the SDK need only implement one or the other and it's up to the runtime to ensure that there's parity in the APIs. We have no need to expose both and have the developer pick one as that would just be confusing. Rather, you've already got HTTP in place, so let's delete the gRPC side.

WhitWaldo · 2025-08-01T15:39:10Z

src/implementation/Client/GRPCClient/jobs.ts

Frankly, I think the SDK should just pick one or the other - if we've got this implemented via HTTP, I don't know we need to have a stub for gRPC (that itself doesn't work) just because as that can lead to developer confusion.

WhitWaldo · 2025-08-01T15:40:05Z

src/implementation/Server/GRPCServer/jobs.ts

As before - if this is implemented using HTTP, no need to add a gRPC implementation just because.

WhitWaldo · 2025-08-01T15:40:46Z

src/types/BuildNumberRange.ts

Could you add a unit test that proves this out?

WhitWaldo · 2025-08-01T15:42:18Z

src/interfaces/Client/IClientJobs.ts

I think the shape of this has changed in the latest protos - I believe there's an override property now.

WhitWaldo · 2025-08-01T15:42:42Z

src/types/jobs/CronExpression.type.ts

+}
+
+export class CronExpression {
+  public static readonly SecondsAndMinutesRegexText = /(?:\*(?:\/[0-5]?\d)?|(?:[0-5]?\d)(?:-(?:[0-5]?\d))?(?:,(?:[0-5]?\d)(?:-(?:[0-5]?\d))?)*)/;


Please add unit tests to prove each of these regexes

WhitWaldo · 2025-08-01T15:45:21Z

src/types/jobs/CronExpression.type.ts

+      .join(",");
+  }
+
+  private prepareDayOfWeekValueList(dayOfWeekValues: DayOfWeek[]) {


As this doesn't reference DayOfWeekValues, are you sure this will sort properly?

WhitWaldo · 2025-08-01T15:50:51Z

test/e2e/jobs/jobs.test.ts

I'd just generally like to see much better test coverage to prove there are no typos in each of the helper extension implementations.

WhitWaldo · 2025-08-01T15:51:48Z

test/unit/jobs/cron.test.ts

When putting together each of the regex variations, just do a quick pass to make sure any seemingly edge cases are covered.

atrauzzi changed the title ~~feat:~~ feat: add jobs Mar 15, 2025

atrauzzi force-pushed the add-jobs branch from 9d97320 to b0bd1b7 Compare March 15, 2025 22:51

WhitWaldo assigned atrauzzi Mar 16, 2025

WhitWaldo added the area/jobs label Mar 16, 2025

WhitWaldo added this to the v3.6.0 milestone Mar 16, 2025

WhitWaldo requested changes Mar 17, 2025

View reviewed changes

WhitWaldo reviewed Mar 18, 2025

View reviewed changes

src/types/jobs/CronExpression.type.ts Outdated Show resolved Hide resolved

WhitWaldo requested changes Mar 18, 2025

View reviewed changes

src/types/jobs/CronExpression.type.ts Outdated Show resolved Hide resolved

WhitWaldo requested changes Mar 22, 2025

View reviewed changes

atrauzzi added a commit to atrauzzi/dapr-js-sdk that referenced this pull request Mar 22, 2025

Cleaning.

577821a

- Addresses - dapr#688 (comment) - dapr#688 (comment) Signed-off-by: Alexander Trauzzi <[email protected]>

ConstantinChirila reviewed Mar 26, 2025

View reviewed changes

joebowbeer reviewed Apr 19, 2025

View reviewed changes