Stripe M2 Reader goes in Autoupdate mode affecting sales

[madinaapps]

Summary

Our Enviornment Reader : Stripe M2 Connectivity is Via USB SDK : com.stripe:stripeterminal:4.0.0 Android Version : 8.5

We have build android app to accept payments using above configuration. We started seeing following issue for last few days.

Every time we switch Stripe account and connect reader goes in auto update mode. It waits there for 1-2 minutes to finish process and its affecting our sales.

Even after M2 reader is updated then also it goes in auto update mode.

What can be done to stop this behavior

Hamid

Code to reproduce

Android version

Impacted devices (Android devices or readers)

SDK version

Other information

[CoderzHeaven]

We are facing the same issue as well. Reader keeps downloading and installing everytime we switch accounts and gets stuck.

[bric-stripe]

Hi, could you provide a serial number and/or two account ids that are getting hit with this?

[madinaapps]

STRM26229006154

acct_1CS5GlLcGDKFzSC2 epic.sadaqa acct_18sbvKEIxcQ1y6BX epic.operations

[bric-stripe]

Thanks for providing that serial and those accounts. We found and fixed a backend issue that was causing this so this should be resolved now. Please let us know if you're still seeing it though.

[madinaapps]

was it resolved only for 2 specific accounts are it was resolved in general.

[bric-stripe]

It was resolved for all accounts.

[dmatthews-stripe]

@madinaapps we are closing this issue as it has been resolved, please feel free to re-open or open a new ticket if you still continue to have issues.

[CoderzHeaven]

Hi, We are having same issues again, Could you please check it ASAP. Thanks.

[bric-stripe]

@CoderzHeaven can you share a reader serial number that is experiencing this? On Nov 10th the latest M2 update became required so all readers should be updating to version 2.01.00.21.SZZZ.01-SZZZ_Prod_US_v10-481001. If a reader isn't on that version the update would be expected but then when switching accounts it should stay on that version.

[CoderzHeaven]

Its the same readers we gave above.

Also there is a new crash happening now

Corrupt proto payload in the queue: terminal_sdk_wire_metrics java.io.EOFException at com.squareup.wire.ProtoReader.internalNextLengthDelimited(ProtoReader.kt:152) at com.squareup.wire.ProtoReader.nextTag(ProtoReader.kt:184) at com.stripe.proto.api.gator.EventResultPb$Companion$ADAPTER$1.decode(EventResultPb.kt:421) at com.stripe.proto.api.gator.EventResultPb$Companion$ADAPTER$1.decode(EventResultPb.kt:286) at com.stripe.proto.api.gator.ProxyEventPb$Companion$ADAPTER$1.decode(ProxyEventPb.kt:210) at com.stripe.proto.api.gator.ProxyEventPb$Companion$ADAPTER$1.decode(ProxyEventPb.kt:164) at com.squareup.wire.ProtoAdapter.decode(ProtoAdapter.kt:457) at com.squareup.wire.ProtoAdapter.decode(ProtoAdapter.kt:455) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileProtoSerializer.fromBytes(QueueFileProtoSerializer.kt:27) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileProtoSerializer.fromBytes(QueueFileProtoSerializer.kt:11) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.populateBatch(QueueFileCollector.kt:245) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.access$populateBatch(QueueFileCollector.kt:26) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector$peek$2.invokeSuspend(QueueFileCollector.kt:180) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644) at java.lang.Thread.run(Thread.java:1012) terminal_sdk_wire_events batch of size 12 generated. terminal_sdk_wire_traces_2 batch of size 32 generated. Background concurrent copying GC freed 11MB AllocSpace bytes, 158(7964KB) LOS objects, 49% free, 18MB/37MB, paused 785us,73us total 108.951ms Input channel destroyed: 'ClientS', fd=199 FATAL EXCEPTION: main Process: com.madinaapps.madinaappskiosk, PID: 13758 java.lang.NegativeArraySizeException: -1592786944 at com.squareup.tape2.QueueFile$ElementIterator.next(QueueFile.java:549) at com.squareup.tape2.QueueFile$ElementIterator.next(QueueFile.java:514) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.populateBatch(QueueFileCollector.kt:425) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.access$populateBatch(QueueFileCollector.kt:26) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector$peek$2.invokeSuspend(QueueFileCollector.kt:180) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644) at java.lang.Thread.run(Thread.java:1012) Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [CoroutineName(AppScope), StandaloneCoroutine{Cancelling}@a60cbbe, Dispatchers.Main.immediate] Sending signal. PID: 13758 SIG: 9

[bric-stripe]

According to our logs STRM26229006154 hasn't been installing updates in the last week. Are you able to capture adb logcat logs from a run where you're seeing that issue?

please file a new issue for the exception so we can track that separately, including any repro steps or scenarios where you're hitting that if possible.

[CoderzHeaven]

What is the reason for the reader not updating? Also why would it crash the app if the reader is not updated? how can it be captured from dev side? It crashes all the time Terminal is initialized. The logs from the adb are pasted above.

STRM26142076758

[CoderzHeaven]

Also the reader is not connecting the the app after it is sitting connected overnight. Its not even proceeding to initialize the Terminal.

[madinaapps]

We at MadinaAPPS are using Multiple Stripe M2 readers at 650+ Locations. All of it uses commercial hardwired Android Tablets version 8.1 and above with M2 readers connected Via USB. These all are unattended in person payments.

We can not afford to have any firmware upgrades during business hours. We are now slowly pushing out builds with com.stripe:stripeterminal:4.0.0

Earlier We noticed there was glitch (it was updating firmware in continuously after changing accounts) from your end which was fixed. System were workign well for few weeks but 2 days back on Friday we saw a similar issue at one client which uses multiple accounts. Friday is most busy day for our clients. Their reader was already updated but it went in autoupdate mode again.

1) How often these stripe m2 firmware upgrader happens ? 2) Our Stripe M2 readers are always connected via USB but looks like that gets disconnected automatically when not in use. 3) We have read the documentation that readers will update on its on at midnight. but this seems to be not happening 4) Is there any best practices. Code that we can implement for checking and updating updates on some set frequencies. 5)Can we avoid autoupdates completely. 6) Can we arrange short 1:1 call with your team.

[madinaapps]

Its the same readers we gave above.

Also there is a new crash happening now

Corrupt proto payload in the queue: terminal_sdk_wire_metrics java.io.EOFException at com.squareup.wire.ProtoReader.internalNextLengthDelimited(ProtoReader.kt:152) at com.squareup.wire.ProtoReader.nextTag(ProtoReader.kt:184) at com.stripe.proto.api.gator.EventResultPb$Companion$ADAPTER$1.decode(EventResultPb.kt:421) at com.stripe.proto.api.gator.EventResultPb$Companion$ADAPTER$1.decode(EventResultPb.kt:286) at com.stripe.proto.api.gator.ProxyEventPb$Companion$ADAPTER$1.decode(ProxyEventPb.kt:210) at com.stripe.proto.api.gator.ProxyEventPb$Companion$ADAPTER$1.decode(ProxyEventPb.kt:164) at com.squareup.wire.ProtoAdapter.decode(ProtoAdapter.kt:457) at com.squareup.wire.ProtoAdapter.decode(ProtoAdapter.kt:455) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileProtoSerializer.fromBytes(QueueFileProtoSerializer.kt:27) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileProtoSerializer.fromBytes(QueueFileProtoSerializer.kt:11) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.populateBatch(QueueFileCollector.kt:245) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.access$populateBatch(QueueFileCollector.kt:26) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector$peek$2.invokeSuspend(QueueFileCollector.kt:180) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644) at java.lang.Thread.run(Thread.java:1012) terminal_sdk_wire_events batch of size 12 generated. terminal_sdk_wire_traces_2 batch of size 32 generated. Background concurrent copying GC freed 11MB AllocSpace bytes, 158(7964KB) LOS objects, 49% free, 18MB/37MB, paused 785us,73us total 108.951ms Input channel destroyed: 'ClientS', fd=199 FATAL EXCEPTION: main Process: com.madinaapps.madinaappskiosk, PID: 13758 java.lang.NegativeArraySizeException: -1592786944 at com.squareup.tape2.QueueFile$ElementIterator.next(QueueFile.java:549) at com.squareup.tape2.QueueFile$ElementIterator.next(QueueFile.java:514) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.populateBatch(QueueFileCollector.kt:425) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector.access$populateBatch(QueueFileCollector.kt:26) at com.stripe.jvmcore.batchdispatcher.collectors.QueueFileCollector$peek$2.invokeSuspend(QueueFileCollector.kt:180) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644) at java.lang.Thread.run(Thread.java:1012) Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [CoroutineName(AppScope), StandaloneCoroutine{Cancelling}@a60cbbe, Dispatchers.Main.immediate] Sending signal. PID: 13758 SIG: 9

Any updates on this crash ?