# How to fix late PubSub message in Extension

**URL:** <https://discuss.dev.twitch.com/t/how-to-fix-late-pubsub-message-in-extension/39082>\
**Category:** Extensions\
**Created:** [June 23, 2022, 11:03am UTC](https://discuss.dev.twitch.com/t/how-to-fix-late-pubsub-message-in-extension/39082 "2022-06-23T11:03:51Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![GroovyKoala](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/groovykoala/32/17918_2.png) [@GroovyKoala](https://discuss.dev.twitch.com/u/GroovyKoala)\
**Post date:** [June 23, 2022, 11:03am UTC](https://discuss.dev.twitch.com/t/how-to-fix-late-pubsub-message-in-extension/39082/1 "2022-06-23T11:03:51Z")

</div>

Hello! I’ve been testing the PubSub system with a client publishing to PubSub through the API using this endpoint `https://api.twitch.tv/helix/extensions/pubsub`, with a `POST` and getting a `204` code.

But I’ve noticing something weird with the messages arriving to the Extension. It’s listening to the `broadcast` topic and those messages doesn’t arriving in order, some may take up to two minutes or even don’t arrive to the Extension. Also if we publish or request to PubSub more than three in a row, the Extension will receive a burst of messages almost instantly (5s delay).

Is there a way to fix this or it’s the expected behaviour of the PubSub Service?

Thanks

---

<div class="post-metadata">

**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\
**Post date:** [June 23, 2022, 11:21am UTC](https://discuss.dev.twitch.com/t/how-to-fix-late-pubsub-message-in-extension/39082/2 "2022-06-23T11:21:23Z")

</div>

I am unable to replicate this.

And have no reports of issues from users of my extensions.

---

<div class="post-metadata">

**Author:** ![GroovyKoala](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/groovykoala/32/17918_2.png) [@GroovyKoala](https://discuss.dev.twitch.com/u/GroovyKoala)\
**Post date:** [June 24, 2022, 7:59am UTC](https://discuss.dev.twitch.com/t/how-to-fix-late-pubsub-message-in-extension/39082/3 "2022-06-24T07:59:22Z")

</div>

I think it’s related to having the listener inside the `onAuthorized` method. Also performed some improvements on the EBS and now the issue is fixed.

Now the messages from a client to the Extension take around 500ms to 1s!

Thanks!

---

<div class="post-metadata">

**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\
**Post date:** [June 24, 2022, 10:11am UTC](https://discuss.dev.twitch.com/t/how-to-fix-late-pubsub-message-in-extension/39082/4 "2022-06-24T10:11:56Z")

</div>

> [@GroovyKoala](#):
>
> I think it’s related to having the listener inside the `onAuthorized` method.

My listen requests (in all my active/released extensions) are also in the `onAuthorized` callback (with a “check” for it it’s an additional callback to prevent duplicate listens)

`onAuthorized` means the extension is ready to go and has the relevant authorization to start making listen requests and other calls.

My “spot test” is [GitHub - BarryCarlyon/twitch\_extension\_debug: A sample Extension that has logic to test MOST Twitch Extension JS Helper Features. Is GH-Pages hosted for easy quick testing!](https://github.com/barrycarlyon/twitch_extension_debug) which `bindListens` in `onAuthorized` ( ~~without the dupe callback check since it’s a spot tester~~ )

So having listens inside `onAuthorized` is the correct way to build an extension.  
If your listens are not inside `onAuthorized` then you might try to `listen` before the extension is ready.

A registered callback to a thing doesn’t matter where the callback is registered as this shouldn’t have any bearing on pubsub speed of delivery. Sure if the page has been open MANY hours and your code has created MANY duplicate listens it might do a weird. but the pubsub message arrives relatively instanteously it’ll just bog down in the JS as it gets duplicate processed.

So whatever change you made as to _when_ you listen shouldn’t have made an effect of the speed of delivery.