![MatterLink](https://media.forgecdn.net/avatars/thumbnails/141/245/256/256/636540604549161691.png)
Server crash
Lgmrszd opened this issue ยท 3 comments
Apparently server crashes when empty message or message containing some special symbols sent, but I'm not sure
Crash log: https://pastebin.com/akB9BMKG
We are seeing this suddenly as well.
Was working fine on our server and then suddenly the server crashed with this error and now we cannot get it to start:
Time: 1/4/20 4:16 PM
Description: Exception in server tick loop
java.lang.RuntimeException: matterlink.repack.com.github.kittinunf.fuel.core.FuelError: The input has already been written to an output stream and can not be consumed again.
matterlink.repack.com.github.kittinunf.fuel.core.FuelError$Companion.wrap(FuelError.kt:85)
matterlink.repack.com.github.kittinunf.fuel.core.FuelError$Companion.wrap$default(FuelError.kt:83)
Caused by: java.lang.IllegalStateException: The input has already been written to an output stream and can not be consumed again.
matterlink.repack.com.github.kittinunf.fuel.core.requests.DefaultBody$Companion$CONSUMED_STREAM$1.invoke(DefaultBody.kt:70)
matterlink.repack.com.github.kittinunf.fuel.core.requests.DefaultBody$Companion$CONSUMED_STREAM$1.invoke(DefaultBody.kt:64)
matterlink.repack.com.github.kittinunf.fuel.core.requests.DefaultBody.writeTo(DefaultBody.kt:42)
matterlink.repack.com.github.kittinunf.fuel.core.requests.DefaultBody.toByteArray(DefaultBody.kt:26)
matterlink.repack.com.github.kittinunf.fuel.core.extensions.FormattingKt.cUrlString(Formatting.kt:46)
matterlink.api.MessageHandler$senderActor$1.invokeSuspend(MessageHandler.kt:174)
kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
matterlink.repack.kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:236)
matterlink.repack.kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594)
matterlink.repack.kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
matterlink.repack.kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:742)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:189)
at net.minecraftforge.fml.common.FMLCommonHandler.onPostServerTick(FMLCommonHandler.java:266)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:712)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526)
at java.lang.Thread.run(Thread.java:748)
Found our issue, the ingress on our api url was throwing a 404...
2020-01-04 16:38:08,875 : INFO : [Server thread/ERROR]: HTTP Exception 404 Not Found
2020-01-04 16:38:09,138 : INFO : [DefaultDispatcher-worker-1/ERROR]: connectErrors: 1
2020-01-04 16:38:09,139 : INFO : [DefaultDispatcher-worker-1/ERROR]: connection error
2020-01-04 16:38:09,173 : INFO : [DefaultDispatcher-worker-1/ERROR]: curl: curl -i -H "Authorization:Bearer <token>" https://matterbridge.routh.io/api/stream
2020-01-04 16:38:09,174 : INFO : [DefaultDispatcher-worker-1/ERROR]: HTTP Exception 404 Not Found
2020-01-04 16:38:09,552 : INFO : [DefaultDispatcher-worker-4/ERROR]: failed to deliver: {"username":"Server","text":"Server started, connecting to matterbridge API","gateway":"multifarious-1"}
2020-01-04 16:38:09,554 : INFO : [DefaultDispatcher-worker-4/ERROR]: url: https://matterbridge.routh.io/api/message
2020-01-04 16:38:10,903 : INFO : Exception in thread "DefaultDispatcher-worker-4" Exception in thread "DefaultDispatcher-worker-4" [Server thread/ERROR]: Could not check for updates!
2020-01-04 16:38:10,904 : INFO : [Server thread/ERROR]: cUrl: curl -i -H "User-Agent:MatterLink/1.6.4 MinecraftForge/1.12.2-14.23.5.2847 (https://github.com/elytra/MatterLink)" https://curse.nikky.moe/api/addon/287323/files
2020-01-04 16:38:10,910 : INFO : [Server thread/ERROR]: request: --> GET https://curse.nikky.moe/api/addon/287323/files
So the crash is caused by a connection error, which shouldn't happen.. Must be an issue with the startup logic. Since this mod can be connected or disconnected from the bridge, getting an error on the initial connect on startup shouldn't be causing a server crash.