tgbotapi.behaviour_builder/dev.inmo.tgbotapi.extensions.behaviour_builder.triggers_handling/onShippingQuery

onShippingQuery

suspend fun <BC : BehaviourContext> BC.onShippingQuery(initialFilter: SimpleFilter<ShippingQuery>? = null, subcontextUpdatesFilter: CustomBehaviourContextAndTwoTypesReceiver<BC, Boolean, ShippingQuery, Update>? = ShippingQueryFilterByUser, markerFactory: MarkerFactory<in ShippingQuery, Any>? = ByUserShippingQueryMarkerFactory, scenarioReceiver: CustomBehaviourContextAndTypeReceiver<BC, Unit, ShippingQuery>): Job

Please, remember that you must answer to this type of queries using something like dev.inmo.tgbotapi.extensions.api.answers.payments.answerShippingQueryOk or dev.inmo.tgbotapi.extensions.api.answers.payments.answerShippingQueryError

Parameters

initialFilter

This filter will be called to remove unnecessary data BEFORE scenarioReceiver call

subcontextUpdatesFilter

This filter will be applied to each update inside of scenarioReceiver. For example, this filter will be used if you will call dev.inmo.tgbotapi.extensions.behaviour_builder.expectations.waitContentMessage. Use dev.inmo.tgbotapi.extensions.behaviour_builder.BehaviourContextAndTwoTypesReceiver function to create your own. Use dev.inmo.tgbotapi.extensions.behaviour_builder.utils.plus or dev.inmo.tgbotapi.extensions.behaviour_builder.utils.times to combinate several filters

markerFactory

Pass null to handle requests fully parallel. Will be used to identify different "stream". scenarioReceiver will be called synchronously in one "stream". Output of markerFactory will be used as a key for "stream"

scenarioReceiver

Main callback which will be used to handle incoming data if initialFilter will pass that data