AppSignal currently collects ActiveJob arguments for error and performance events even when a job is configured with log_arguments = false. This can cause sensitive data to appear in AppSignal despite Rails being explicitly configured not to log them.
This enhancement proposes that AppSignal respects log_arguments = false when instrumenting ActiveJob, both when it is configured globally (e.g. on ApplicationJob) and per job class.
This is problematic for jobs like ActionMailer::MailDeliveryJob and DeviseMailers as they could use plain string arguments, which cannot be filtered using filter_parameters.
Intercom
Proposed behavior
When instrumenting ActiveJob, we should check the job’s effective log_arguments setting (including inherited values). If job.class.log_arguments == false, job arguments should not be collected or reported (or should be replaced with [FILTERED])
This behavior should apply:
- when
log_arguments is set globally on ApplicationJob
- when it is set on individual
ActiveJob classes
Acceptance criteria:
AppSignal currently collects
ActiveJobarguments for error and performance events even when a job is configured withlog_arguments = false. This can cause sensitive data to appear in AppSignal despite Rails being explicitly configured not to log them.This enhancement proposes that AppSignal respects
log_arguments = falsewhen instrumentingActiveJob, both when it is configured globally (e.g. onApplicationJob) and per job class.This is problematic for jobs like
ActionMailer::MailDeliveryJoband DeviseMailers as they could use plain string arguments, which cannot be filtered usingfilter_parameters.Intercom
Proposed behavior
When instrumenting ActiveJob, we should check the job’s effective
log_argumentssetting (including inherited values). Ifjob.class.log_arguments == false, job arguments should not be collected or reported (or should be replaced with[FILTERED])This behavior should apply:
log_argumentsis set globally onApplicationJobActiveJobclassesAcceptance criteria: