I'm getting an error when trying to stream a txt file from Okhttp (no retrofit) and putting it into sqlDelight. It works like 99% of the time, but sometimes I get an

unexpected end of stream

error. This is roughly my code that takes the bufferedReader from okhttp. Anything look obviously bad here?

suspend fun deleteAllThenInsertAllLines(bufferedReader: BufferedReader) =
withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
    myQueries.transaction {
      myQueries.deleteAll()
      var currentLine: String? = null
      try {
        while (bufferedReader.readLine().also { currentLine = it } != null) {
          myQueries.insert(currentLine)
        }
      } catch (e: Exception) {
        printlin("Exception! Failed on $currentLine with ${e.message}")
      }
    }
  }

I can't say I know for certain why this is happening because I/O is something I have little experience with, but you might try using `Okio`'s

Source

and

Sink

API's. My understanding of Okio is that it's supposed to be a better, safer, and faster wrapper on top of

<http://java.io|java.io>

API's and it's something

OkHttp

depends on already Definitely look at it first though, I don't want to just recommended using a tool that may just end up being overkill for a simple fix.

from a purely code review standpoint,

.useLines {}

is preferred if possible.

.readlnOrNull()

is a better name for

.readLine()

anyhow

I think I had issues with some of the "better" apis for reading lines. lemme find that convo... https://kotlinlang.slack.com/archives/C1CFAFJSK/p1694110868583289

that's not a problem with

useLines

,

bufferedReader.useLines { lines ->
    for (line in lines) {
        // can suspend

I wonder if I need

Chunked transfer encoding

https://stackoverflow.com/a/58217819

T-E:chunked is useful if the server doesn't know the size of the content before sending it, but otherwise not. also it's completely gone in HTTP/2