Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: DaprJobDetails fail to populate when mapped job is invoked #1457

Closed
WhitWaldo opened this issue Feb 10, 2025 · 0 comments
Closed

Bug: DaprJobDetails fail to populate when mapped job is invoked #1457

WhitWaldo opened this issue Feb 10, 2025 · 0 comments
Assignees
Labels
kind/bug Something isn't working P0
Milestone

Comments

@WhitWaldo
Copy link
Contributor

Expected Behavior

While a DaprJobDetails is marked as nullable, it should always be populated with the job details when a job is invoked.

Actual Behavior

In my testing and as reported by someone in Discord, DaprJobDetails is always null.

Steps to Reproduce the Problem

Run Jobs example in Dapr .NET SDK (with fix from PR #1456) and wait for the job to be invoked. Observe the jobDetails parameter not getting populated.

Release Note

RELEASE NOTE: FIX DaprJobDetails properly populating when mapped job is invoked

@WhitWaldo WhitWaldo added the kind/bug Something isn't working label Feb 10, 2025
@WhitWaldo WhitWaldo added this to the v1.15 milestone Feb 10, 2025
@WhitWaldo WhitWaldo self-assigned this Feb 10, 2025
@WhitWaldo WhitWaldo added the P1 label Feb 10, 2025
@WhitWaldo WhitWaldo mentioned this issue Feb 10, 2025
3 tasks
@WhitWaldo WhitWaldo added P0 and removed P1 labels Feb 10, 2025
WhitWaldo added a commit that referenced this issue Feb 11, 2025
fix: Point-in-time not getting scheduled, job payload not being property set on job invocation

When setting a single point-in-time job, the SDK was incorrectly assigning it as a schedule which would promptly fail cron validation. Rather, this now properly sets it to `dueTime` instead. Further, when a Job is invoked, only the payload it was registered with is provided in the callback, not all the elements of a Get Job response, so this was modified to return the `ReadOnlyMemory<byte>` originally provided in the payload back to the caller.

Reviewed by: @philliphoff
Refs: #1455 #1457
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working P0
Projects
None yet
Development

No branches or pull requests

1 participant