{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":787522538,"defaultBranch":"master","name":"cadence-java-client","ownerLogin":"natemort","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2024-04-16T17:25:42.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/1179488?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1714772748.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"ba3df20dbc368a1fd848b03d8a0e4aa6de5059e4","ref":"refs/heads/v3.12","pushedAt":"2024-05-03T21:45:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Release v3.12.0","shortMessageHtmlLink":"Release v3.12.0"}},{"before":"fd688a280451ca57506120332b0bfbc372a2a101","after":"96321f3416beeb5f8db1266cf566994c60db6e42","ref":"refs/heads/master","pushedAt":"2024-05-03T19:48:15.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Release v3.12.0","shortMessageHtmlLink":"Release v3.12.0"}},{"before":"801d9b4bf9974be675c522dcc7c985acb3729082","after":"fd688a280451ca57506120332b0bfbc372a2a101","ref":"refs/heads/master","pushedAt":"2024-05-03T19:47:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Lock TestWorkflowStoreImpl when listing workflows (#890)\n\nThis is the only path to the backing histories map that isn't locked. When running a test containing multiple child workflows in parallel where one child workflow attempts to call listWorkflows I'm able to consistently reproduce a concurrent modification exception.\r\n\r\nDespite being a change to locking, this change is rather low risk. The lock is reentrant and there are no other locks acquired while holding this lock, so there's no chance of deadlock. In addition, this codepath isn't use internally at all. It exists only to implement ListOpenWorkflowExecutions and ListClosedWorkflowExecutions on the client, allowing test code to make these RPCs. This is likely why it hasn't been caught before.","shortMessageHtmlLink":"Lock TestWorkflowStoreImpl when listing workflows (uber#890)"}},{"before":"d9a775046a9889acc903aba671bc96ea8b5f110a","after":"801d9b4bf9974be675c522dcc7c985acb3729082","ref":"refs/heads/master","pushedAt":"2024-05-03T19:18:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Bug Fix for null pointer exception in case header getFields is null in workflow context replay (#891)\n\n* Fix for null pointer exception","shortMessageHtmlLink":"Bug Fix for null pointer exception in case header getFields is null i…"}},{"before":"712b4c83248edcbd551e397bc914d0fc362bfe34","after":"9c6eddf2ed1670d374f86d8fe9398445e8d3cb36","ref":"refs/heads/testlock","pushedAt":"2024-05-03T19:17:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Lock TestWorkflowStoreImpl when listing workflows\n\nThis is the only path to the backing histories map that isn't locked. When running a test containing multiple child workflows in parallel where one child workflow attempts to call listWorkflows I'm able to consistently reproduce a concurrent modification exception.\n\nDespite being a change to locking, this change is rather low risk. The lock is reentrant and there are no other locks acquired while holding this lock, so there's no chance of deadlock. In addition, this codepath isn't use internally at all. It exists only to implement ListOpenWorkflowExecutions and ListClosedWorkflowExecutions on the client, allowing test code to make these RPCs. This is likely why it hasn't been caught before.","shortMessageHtmlLink":"Lock TestWorkflowStoreImpl when listing workflows"}},{"before":"80b3ed1bff3b71b740c9d01f92f0b574a4a3750f","after":"712b4c83248edcbd551e397bc914d0fc362bfe34","ref":"refs/heads/testlock","pushedAt":"2024-05-03T17:14:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Lock TestWorkflowStoreImpl when listing workflows\n\nThis is the only path to the backing histories map that isn't locked. When running a test containing multiple child workflows in parallel where one child workflow attempts to call listWorkflows I'm able to consistently reproduce a concurrent modification exception.\n\nDespite being a change to locking, this change is rather low risk. The lock is reentrant and there are no other locks acquired while holding this lock, so there's no chance of deadlock. In addition, this codepath isn't use internally at all. It exists only to implement ListOpenWorkflowExecutions and ListClosedWorkflowExecutions on the client, allowing test code to make these RPCs. This is likely why it hasn't been caught before.","shortMessageHtmlLink":"Lock TestWorkflowStoreImpl when listing workflows"}},{"before":null,"after":"80b3ed1bff3b71b740c9d01f92f0b574a4a3750f","ref":"refs/heads/testlock","pushedAt":"2024-05-03T16:54:24.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Lock TestWorkflowStoreImpl when listing workflows\n\nThis is the only path to the backing histories map that isn't locked. When running a test containing multiple child workflows in parallel where one child workflow attempts to call listWorkflows I'm able to consistently reproduce a concurrent modification exception.\n\nDespite being a change to locking, this change is rather low risk. The lock is reentrant and there are no other locks acquired while holding this lock, so there's no chance of deadlock. In addition, this codepath isn't use internally at all. It exists only to implement ListOpenWorkflowExecutions and ListClosedWorkflowExecutions on the client, allowing test code to make these RPCs. This is likely why it hasn't been caught before.","shortMessageHtmlLink":"Lock TestWorkflowStoreImpl when listing workflows"}},{"before":"8e0e3e2558d5f50a1959e888e2e2c9c0c9e52089","after":"d9a775046a9889acc903aba671bc96ea8b5f110a","ref":"refs/heads/master","pushedAt":"2024-05-03T16:51:53.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"use the \"test\" scope for the io.grpc:grpc-testing dependency (#858)\n\nreduces runtime jar and removes unused classes from the distribution.","shortMessageHtmlLink":"use the \"test\" scope for the io.grpc:grpc-testing dependency (uber#858)"}},{"before":"eae647c5dbca9fd90f668158b2b0ca6e40827fba","after":"8e0e3e2558d5f50a1959e888e2e2c9c0c9e52089","ref":"refs/heads/master","pushedAt":"2024-04-30T21:25:24.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add support for SignalWithStartWorkflowExecutionAsync (#887)\n\nAdd support to schedule a SignalWithStartWorkflowExecution operation to be performed at a future date via SignalWithStartWorkflowExecutionAsync. This is exposed in the java client in two ways:\r\n- WorkflowStub#enqueueSignalWithStart, which presents an untyped interface.\r\n- WorkflowClient#enqueueSignalWithStart, with presents a statically typed interface.\r\n\r\nThe existing mechanisms for SignalWithStart don't currently have an async equivalent so we don't introduce one here.\r\n\r\nAdditionally add full test coverage for tracing information being injected into headers both in GRPC and TChannel.","shortMessageHtmlLink":"Add support for SignalWithStartWorkflowExecutionAsync (uber#887)"}},{"before":null,"after":"247bce8d4fb961a38bf826f132ba7d644a80ee9a","ref":"refs/heads/signalasync","pushedAt":"2024-04-29T23:30:53.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add support for SignalWithStartWorkflowExecutionAsync\n\nAdd support to schedule a SignalWithStartWorkflowExecution operation to be performed at a future date via SignalWithStartWorkflowExecutionAsync. This is exposed in the java client in two ways:\n- WorkflowStub#enqueueSignalWithStart, which presents an untyped interface.\n- WorkflowClient#enqueueSignalWithStart, with presents a statically typed interface.\n\nThe existing mechanisms for SignalWithStart don't currently have an async equivalent so we don't introduce one here.\n\nAdditionally add full test coverage for tracing information being injected into headers both in GRPC and TChannel.","shortMessageHtmlLink":"Add support for SignalWithStartWorkflowExecutionAsync"}},{"before":"bf06a8d9e66bed8f528747bb6447a853de722ef9","after":"eae647c5dbca9fd90f668158b2b0ca6e40827fba","ref":"refs/heads/master","pushedAt":"2024-04-29T23:29:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add statically-typed support for enqueueStart (#886)\n\nThe preferred mechanism for interacting with workflows is via the statically typed interface so that parameter types can be checked at compile time. Add the 14 required overloads of WorkflowClient#enqueueStart to mirror WorkflowClient#start, and implement support for it in WorkflowInvocationHandler.","shortMessageHtmlLink":"Add statically-typed support for enqueueStart (uber#886)"}},{"before":"66f7bc5664532aecd5806ecdb7e28ac566f199b6","after":"318cb5645a29e78f61fcb0be03089ed418f4dbd0","ref":"refs/heads/async","pushedAt":"2024-04-29T19:25:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add statically-typed support for enqueueStart\n\nThe preferred mechanism for interacting with workflows is via the statically typed interface so that parameter types can be checked at compile time. Add the 14 required overloads of WorkflowClient#enqueueStart to mirror WorkflowClient#start, and implement support for it in WorkflowInvocationHandler.","shortMessageHtmlLink":"Add statically-typed support for enqueueStart"}},{"before":"085ec65361cc052a85d62212e496fae634e1b41a","after":"66f7bc5664532aecd5806ecdb7e28ac566f199b6","ref":"refs/heads/async","pushedAt":"2024-04-29T19:10:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add statically-typed support for enqueueStart\n\nThe preferred mechanism for interacting with workflows is via the statically typed interface so that parameter types can be checked at compile time. Add the 14 required overloads of WorkflowClient#enqueueStart to mirror WorkflowClient#start, and implement support for it in WorkflowInvocationHandler.","shortMessageHtmlLink":"Add statically-typed support for enqueueStart"}},{"before":"ec10e2bea930bba763c0364fe0861cc77010eca8","after":"bf06a8d9e66bed8f528747bb6447a853de722ef9","ref":"refs/heads/master","pushedAt":"2024-04-29T19:08:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add initial support for StartWorkflowExecutionAsync (#884)\n\nAdd WorkflowStub#enqueueStart which uses the new StartWorkflowExecutionAsync to submit a workflow to be started at some point in the future.\r\n\r\nCurrently nearly all testing of the Cadence Java client is implemented as integration tests in WorkflowTests, running against either a locally running Cadence service or using the test environment. While this approach would be technically possible to configure (adding zookeeper and kafka to the docker-compose files), this would require reimplementing the integration tests already present on the Cadence server for all new features added. This approach doesn't scale well for adding new functionality to each client.\r\n\r\nInstead, we add tests for this functionality via targeted unit tests at the different layers of the client. Add WorkflowClientInternalTest to use an in-memory fake server with stubbed responses to assert that we make exactly the correct request. This tests the entire Tchannel networking stack of the client end to end. Add WorkflowStubImplTest to test the specific semantics and state of the WorkflowStubImpl. State is particularly important with WorkflowStubs as they're intended to represent a single execution of a Workflow, so they normally capture the Workflow runId when starting a workflow. For StartWorkflowExecutionAsync we capture only the workflowId so that a stub can be used to enqueueStart(), then later qury or signal that workflow.\r\n\r\nAdditionally add tests for the thrift2proto mappers, including the MapperTestUtil assertions to ensure that all fields are present. This ensures that any update to the IDL files requires a corresponding change to either the test or mapper to account for the new field.","shortMessageHtmlLink":"Add initial support for StartWorkflowExecutionAsync (uber#884)"}},{"before":"ac66eb9f2943541c4aacad77b76c96269c0278a8","after":"085ec65361cc052a85d62212e496fae634e1b41a","ref":"refs/heads/async","pushedAt":"2024-04-29T18:00:15.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Change return type to WorkflowExecution","shortMessageHtmlLink":"Change return type to WorkflowExecution"}},{"before":"bfd521dc895a59ffb2ba17875f828072e36a64b1","after":"ec10e2bea930bba763c0364fe0861cc77010eca8","ref":"refs/heads/master","pushedAt":"2024-04-29T18:00:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Fix flakiness in LoggerTest (#885)\n\nIf any other threads logs a message while we iterate over the events it can throw a ConcurrentModificationException.\r\n\r\nCreate our own implementation of ListAppender that uses the synchronized keyword to protect reading/writing to the backing list with a mutex. Create a copy of the list while holding to the lock to support iterating over it.","shortMessageHtmlLink":"Fix flakiness in LoggerTest (uber#885)"}},{"before":"952a3b380d45918a8bbe02d56a150035a4781d9a","after":"ac66eb9f2943541c4aacad77b76c96269c0278a8","ref":"refs/heads/async","pushedAt":"2024-04-29T17:08:03.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"shijiesheng","name":"Shijie Sheng","path":"/shijiesheng","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9356964?s=80&v=4"},"commit":{"message":"Merge branch 'master' into async","shortMessageHtmlLink":"Merge branch 'master' into async"}},{"before":"8997b0fcc3dea39d585bf1748540205620ee8ff2","after":"952a3b380d45918a8bbe02d56a150035a4781d9a","ref":"refs/heads/async","pushedAt":"2024-04-26T23:44:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Change return type to WorkflowExecution","shortMessageHtmlLink":"Change return type to WorkflowExecution"}},{"before":"42e737930b434d49e9ae57a461a870fe52b54834","after":"8997b0fcc3dea39d585bf1748540205620ee8ff2","ref":"refs/heads/async","pushedAt":"2024-04-26T20:30:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Change return type to WorkflowExecution","shortMessageHtmlLink":"Change return type to WorkflowExecution"}},{"before":"c4755f3612896eb5cca6e7796bcccf8b4dd2f8e3","after":"42e737930b434d49e9ae57a461a870fe52b54834","ref":"refs/heads/async","pushedAt":"2024-04-26T19:13:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add initial support for StartWorkflowExecutionAsync\n\nAdd WorkflowStub#enqueueStart which uses the new StartWorkflowExecutionAsync to submit a workflow to be started at some point in the future.\n\nCurrently nearly all testing of the Cadence Java client is implemented as integration tests in WorkflowTests, running against either a locally running Cadence service or using the test environment. While this approach would be technically possible to configure (adding zookeeper and kafka to the docker-compose files), this would require reimplementing the integration tests already present on the Cadence server for all new features added. This approach doesn't scale well for adding new functionality to each client.\n\nInstead, we add tests for this functionality via targeted unit tests at the different layers of the client. Add WorkflowClientInternalTest to use an in-memory fake server with stubbed responses to assert that we make exactly the correct request. This tests the entire Tchannel networking stack of the client end to end. Add WorkflowStubImplTest to test the specific semantics and state of the WorkflowStubImpl. State is particularly important with WorkflowStubs as they're intended to represent a single execution of a Workflow, so they normally capture the Workflow runId when starting a workflow. For StartWorkflowExecutionAsync we capture only the workflowId so that a stub can be used to enqueueStart(), then later qury or signal that workflow.\n\nAdditionally add tests for the thrift2proto mappers, including the MapperTestUtil assertions to ensure that all fields are present. This ensures that any update to the IDL files requires a corresponding change to either the test or mapper to account for the new field.","shortMessageHtmlLink":"Add initial support for StartWorkflowExecutionAsync"}},{"before":null,"after":"cc4064f9eff923a5e5d4d0372390d1e1703a5a22","ref":"refs/heads/loggertest","pushedAt":"2024-04-25T23:06:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Fix flakiness in LoggerTest\n\nIf any other threads logs a message while we iterate over the events it can throw a ConcurrentModificationException.\n\nCreate our own implementation of ListAppender that uses the synchronized keyword to protect reading/writing to the backing list with a mutex. Create a copy of the list while holding to the lock to support iterating over it.","shortMessageHtmlLink":"Fix flakiness in LoggerTest"}},{"before":"a5e39f7eee1984ceb9eb41f512cba2e7de66c7dd","after":"c4755f3612896eb5cca6e7796bcccf8b4dd2f8e3","ref":"refs/heads/async","pushedAt":"2024-04-25T22:56:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add initial support for StartWorkflowExecutionAsync\n\nAdd WorkflowStub#enqueueStart which uses the new StartWorkflowExecutionAsync to submit a workflow to be started at some point in the future.\n\nCurrently nearly all testing of the Cadence Java client is implemented as integration tests in WorkflowTests, running against either a locally running Cadence service or using the test environment. While this approach would be technically possible to configure (adding zookeeper and kafka to the docker-compose files), this would require reimplementing the integration tests already present on the Cadence server for all new features added. This approach doesn't scale well for adding new functionality to each client.\n\nInstead, we add tests for this functionality via targeted unit tests at the different layers of the client. Add WorkflowClientInternalTest to use an in-memory fake server with stubbed responses to assert that we make exactly the correct request. This tests the entire Tchannel networking stack of the client end to end. Add WorkflowStubImplTest to test the specific semantics and state of the WorkflowStubImpl. State is particularly important with WorkflowStubs as they're intended to represent a single execution of a Workflow, so they normally capture the Workflow runId when starting a workflow. For StartWorkflowExecutionAsync we capture only the workflowId so that a stub can be used to enqueueStart(), then later qury or signal that workflow.\n\nAdditionally add tests for the thrift2proto mappers, including the MapperTestUtil assertions to ensure that all fields are present. This ensures that any update to the IDL files requires a corresponding change to either the test or mapper to account for the new field.","shortMessageHtmlLink":"Add initial support for StartWorkflowExecutionAsync"}},{"before":"a351cb7109a367888c0763427bde73923b92e445","after":"a5e39f7eee1984ceb9eb41f512cba2e7de66c7dd","ref":"refs/heads/async","pushedAt":"2024-04-25T22:34:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Add initial support for StartWorkflowExecutionAsync\n\nAdd WorkflowStub#enqueueStart which uses the new StartWorkflowExecutionAsync to submit a workflow to be started at some point in the future.\n\nCurrently nearly all testing of the Cadence Java client is implemented as integration tests in WorkflowTests, running against either a locally running Cadence service or using the test environment. While this approach would be technically possible to configure (adding zookeeper and kafka to the docker-compose files), this would require reimplementing the integration tests already present on the Cadence server for all new features added. This approach doesn't scale well for adding new functionality to each client.\n\nInstead, we add tests for this functionality via targeted unit tests at the different layers of the client. Add WorkflowClientInternalTest to use an in-memory fake server with stubbed responses to assert that we make exactly the correct request. This tests the entire Tchannel networking stack of the client end to end. Add WorkflowStubImplTest to test the specific semantics and state of the WorkflowStubImpl. State is particularly important with WorkflowStubs as they're intended to represent a single execution of a Workflow, so they normally capture the Workflow runId when starting a workflow. For StartWorkflowExecutionAsync we capture only the workflowId so that a stub can be used to enqueueStart(), then later qury or signal that workflow.\n\nAdditionally add tests for the thrift2proto mappers, including the MapperTestUtil assertions to ensure that all fields are present. This ensures that any update to the IDL files requires a corresponding change to either the test or mapper to account for the new field.","shortMessageHtmlLink":"Add initial support for StartWorkflowExecutionAsync"}},{"before":"754a088e3bef67e866545090251cbfa020724036","after":"bfd521dc895a59ffb2ba17875f828072e36a64b1","ref":"refs/heads/master","pushedAt":"2024-04-25T22:26:30.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Changed WorkerOption to fallback and use WorkflowClient tracer instead of NoopTracer (#883)\n\nWhat changed?\r\n\r\nWorkflowOptions will now fallback and use WorkflowClient's tracer.\r\nExpose getOptions on IWorkflowService interface.\r\nWhy?\r\n\r\nMake it easier to set tracer. Previously, it's required to set tracer both on the client and worker. Now setting tracer only on client should just work.\r\n\r\nHow did you test it?\r\n\r\nUnit Test","shortMessageHtmlLink":"Changed WorkerOption to fallback and use WorkflowClient tracer instea…"}},{"before":"887646d7d4aa7066d60a34817a91154285991602","after":"a351cb7109a367888c0763427bde73923b92e445","ref":"refs/heads/async","pushedAt":"2024-04-19T15:02:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"fix missed methods","shortMessageHtmlLink":"fix missed methods"}},{"before":"d76cd26aa9ebe24a213a8ca53b134f57c2382314","after":"887646d7d4aa7066d60a34817a91154285991602","ref":"refs/heads/async","pushedAt":"2024-04-18T23:21:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"fix missed methods","shortMessageHtmlLink":"fix missed methods"}},{"before":"75379beca258a0b3946825d196b5898ab76f5e33","after":"b568c5e18d80e7885f50b7264a0e9f35d79d05af","ref":"refs/heads/allof","pushedAt":"2024-04-18T23:12:53.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"shijiesheng","name":"Shijie Sheng","path":"/shijiesheng","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9356964?s=80&v=4"},"commit":{"message":"Merge branch 'master' into allof","shortMessageHtmlLink":"Merge branch 'master' into allof"}},{"before":"aad5caa92e51b079a4ace22863c35ab6ae2da297","after":"d76cd26aa9ebe24a213a8ca53b134f57c2382314","ref":"refs/heads/async","pushedAt":"2024-04-18T22:39:14.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"fix missed methods","shortMessageHtmlLink":"fix missed methods"}},{"before":null,"after":"aad5caa92e51b079a4ace22863c35ab6ae2da297","ref":"refs/heads/async","pushedAt":"2024-04-18T22:32:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Implement required methods for new IDL types","shortMessageHtmlLink":"Implement required methods for new IDL types"}},{"before":"c7f84272320705d9eaeefd56bd9e043f95ebda28","after":"75379beca258a0b3946825d196b5898ab76f5e33","ref":"refs/heads/allof","pushedAt":"2024-04-18T20:51:00.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"natemort","name":"Nate Mortensen","path":"/natemort","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1179488?s=80&v=4"},"commit":{"message":"Fix wildcard imports intellij added","shortMessageHtmlLink":"Fix wildcard imports intellij added"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEQSKb4wA","startCursor":null,"endCursor":null}},"title":"Activity · natemort/cadence-java-client"}