[
https://issues.apache.org/jira/browse/GOBBLIN-1764?focusedWorklogId=839152&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-839152
]
ASF GitHub Bot logged work on GOBBLIN-1764:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Jan/23 21:10
Start Date: 13/Jan/23 21:10
Worklog Time Spent: 10m
Work Description: phet commented on code in PR #3623:
URL: https://github.com/apache/gobblin/pull/3623#discussion_r1070057390
##########
gobblin-service/src/main/java/org/apache/gobblin/service/monitoring/KafkaJobStatusMonitor.java:
##########
@@ -219,7 +229,8 @@ protected void
processMessage(DecodeableKafkaRecord<byte[],byte[]> message) {
* @throws IOException
*/
@VisibleForTesting
- static void addJobStatusToStateStore(org.apache.gobblin.configuration.State
jobStatus, StateStore stateStore)
+ static void addJobStatusToStateStore(org.apache.gobblin.configuration.State
jobStatus, StateStore stateStore,
+ Optional<GaaSObservabilityEventProducer> eventProducer)
Review Comment:
I've not heard that debate....
overall, the idea w/ `Optional` is to encode possible absence in the type
system where it can be checked statically and automatically. `null` is
notoriously furtive... take for instance this very impl. (here), which does not
check `stateStore != null`--but should it? the practice I follow is that when
that ought to be checked, the expectation should be stated, not in javadoc or
other code comments, but via `Optional`.
again, I've not heard specific concern w/ use as a parameter type. quite
the opposite, in fact: the use is noted to bring clear benefit.
Issue Time Tracking
-------------------
Worklog Id: (was: 839152)
Time Spent: 1h (was: 50m)
> Emit GaaSObservabilityEvent
> ---------------------------
>
> Key: GOBBLIN-1764
> URL: https://issues.apache.org/jira/browse/GOBBLIN-1764
> Project: Apache Gobblin
> Issue Type: New Feature
> Components: gobblin-service
> Reporter: William Lo
> Assignee: Abhishek Tiwari
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> GaaSObservabilityEvents are a new events that provides a job summary from
> pipelines in GaaS. It differs from GobblinTrackingEvents as it runs once per
> job pipeline, and it intended to be easily queryable and alert on.
> We want to emit this observability event from GaaS by deriving it from a
> job's job status. Since this feature is Experimental and WIP, it is not
> expected to fill out all of the fields immediately.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
