-
Notifications
You must be signed in to change notification settings - Fork 320
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
feat: support for config to custom destinations #2625
feat: support for config to custom destinations #2625
Conversation
…assing config to transformer for custom destinations
Related PR: #2569 |
Codecov ReportBase: 43.85% // Head: 43.84% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2625 +/- ##
==========================================
- Coverage 43.85% 43.84% -0.01%
==========================================
Files 187 187
Lines 40027 40024 -3
==========================================
- Hits 17552 17550 -2
- Misses 21376 21378 +2
+ Partials 1099 1096 -3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good, but is this something that can be done from destination definitions itself? Why keep config at different places?
Ideally yes for a quick fix I went with this appraoch |
is this going to be tech debt again? I prefer to have this to be defined at destDef level so that it is easy to debug and understand. |
Make sense I will try to do an impl |
…iltering via destination definition
@koladilip I have approached the problem with the way you suggested, taking the filter keys from destination definition |
processor/processor.go
Outdated
sent to transformer for such destination. */ | ||
if misc.Contains(customDestinations, *destType) { | ||
shallowEventCopy.Destination.Config = nil | ||
configsToFilter := destination.DestinationDefinition.ConfigFilters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens to range operation if this is nil?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ConfigFilters
won't be nil
as its type Array when initialized it will be an empty array. But we can do a nil check before iterating
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes looks like nil is handled by range so we don't need to worry about: https://play.golang.com/p/iymc4sfOdcw
…efinitionT and checks before accessing values
processor/processor.go
Outdated
sent to transformer for such destination. */ | ||
if misc.Contains(customDestinations, *destType) { | ||
shallowEventCopy.Destination.Config = nil | ||
configsToFilter := destination.DestinationDefinition.ConfigFilters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes looks like nil is handled by range so we don't need to worry about: https://play.golang.com/p/iymc4sfOdcw
…ub.com:rudderlabs/rudder-server into feat.support-for-config-to-custom-destinations
…efinitionT and checks before accessing values
…omments handled type checks
8130004
to
bf60abe
Compare
Added unit test cases |
processor/processor.go
Outdated
|
||
func filterConfig(eventCopy *transformer.TransformerEventT, destination *backendconfig.DestinationT) { | ||
if configsToFilterI, ok := destination.DestinationDefinition.Config["configFilters"]; ok { | ||
if configsToFilter, ok := configsToFilterI.([]string); ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In practice, casting to []string
has no chances for success, since this config will be populated through json unmarshalling.
https://go.dev/play/p/BLqiaLRfgO-
- Please adapt relevant tests to use proper, unmarshalled configs
- Make sure to typecheck the next casting that will be introduced too (
k, ok := configKey.(string); ok
) as a slice ofany
type can literally hold any type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it addressed the same, added unit test cases as well
…to consider array of interface and casting individual types
processor/processor.go
Outdated
@@ -509,7 +508,7 @@ func loadConfig() { | |||
config.RegisterBoolConfigVariable(false, &enableEventSchemasAPIOnly, true, "EventSchemas.enableEventSchemasAPIOnly") | |||
config.RegisterIntConfigVariable(10000, &maxEventsToProcess, true, 1, "Processor.maxLoopProcessEvents") | |||
|
|||
batchDestinations, customDestinations = misc.LoadDestinations() | |||
batchDestinations, _ = misc.LoadDestinations() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since misc.LoadDestinations
is only used here and we don't really care about custom destinations, please simplify it by renaming it to misc.BatchDestinations
and only return a single value
batchDestinations, _ = misc.LoadDestinations() | |
batchDestinations = misc.BatchDestinations() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed
Config: map[string]interface{}{ | ||
"configFilters": []interface{}{"long_config1", "long_config2"}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least once we should use the outcome of json.Unmarshal
in our tests, by unmarshalling a json string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed
…dding test case with unmarshled configs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@utsabc linting was not passing when you merged. can you please open a PR to fix the linting warnings? https://github.com/rudderlabs/rudder-server/actions/runs/3375866788/jobs/5602936742
Sure |
Adding support for passing config to transformer for custom destinations
Description
Previously we were filtering the total config for requests to transformer for custom destinations. Main motivation for it was to avoid making heavy requests as some some configs would contain would contain certificate details etc.
This PR approaches the solution with more general intnet by filtering any destination config based on predefined filters set in integrations module
Notion Ticket
Notion link: https://www.notion.so/rudderstacks/Kafka-Destination-with-Multiple-Topics-85cbce26706d49eca6853b972e5497b0
Security