@@ -435,10 +435,12 @@ include::example$logging/tutorial001.py[]
435435<.> Use `Logger` as every other Python logger.
436436
437437=== Customizations
438- You might want to send logs to other places
438+ You might want to customize app behavior in a several ways,
439+ for example merge incoming events or send logs to other places
439440(e.g., to error reporting systems like
440441<<sentry, `Sentry`>> or <<rollbar, `Rollbar`>>).
441- This can be achieved by providing an instance of
442+
443+ Sending custom logs can be achieved by providing an instance of
442444{python-log-handlers-link}[logging handler]
443445as an argument to app decorator.
444446Custom handler will be used alongside {corva-sdk}'s default one.
@@ -524,6 +526,30 @@ and pass corresponding logging handler
524526as a keyword argument to the app decorator.
525527Use code samples above as the examples.
526528
529+ == Merging incoming events
530+
531+ [TIP]
532+ ====
533+ Only <<stream,`stream`>>
534+ and <<scheduled,`scheduled`>>
535+ apps can use this feature.
536+ ====
537+
538+ Sometimes Corva can send more than one event to @scheduled and @stream apps.
539+ Optionally we can ask to merge them into one event by providing `merge_events=True` parameter.
540+ [source,python]
541+ ----
542+ include::example$merging/tutorial001.py[]
543+ ----
544+ Usually this is needed to save some IO operations by processing data in bigger batches.
545+ Use this parameter with care, in pessimistic scenario you can receive too much data, try to
546+ process it in "one go" and fail with timeout. In that case your app will be automatically
547+ restarted and you will start from the beginning and fail again.
548+ Without this parameter after each processed event corva-sdk will "remember" that event was processed.
549+ So, for example, if you will fail at event #5 and your app will be restarted - app will start processing
550+ from event #5(and not #1 like in case of `merge_events=True`)
551+
552+
527553== Followable apps
528554
529555[TIP]
0 commit comments