Status Update
Comments
jp...@google.com <jp...@google.com> #2
I attached a repro project. This is the stacktrace printed from the Retrofit error (I included the keep rules for the Kodein issue):
java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
at retrofit2.HttpServiceMethod.parseAnnotations(HttpServiceMethod.java:365)
at retrofit2.Retrofit.loadServiceMethod(Retrofit.java:4)
at retrofit2.Retrofit$1.invoke(Retrofit.java:7)
at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
at $Proxy1.getAllBreeds(Unknown Source)
at com.example.api.DogBreedApiImpl.getAllBreeds(DogBreedApi.kt:5)
at com.example.kodein7.MainActivity$onCreate$1.invokeSuspend(MainActivity.kt:5)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:18)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7660)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
ma...@gmail.com <ma...@gmail.com> #4
R8 fullmode will remove all attributes for classes that are not kept. Attributes and annotations can only be read by reflection and for full mode we require an explicit keep rule to keep the signatures (and other attributes).
As you point to, adding keep rules for the types in kodein will force R8 to keep the signatures.
For retrofit, you will have to keep the api classes. Interestingly, you also have to keep the kotlin.coroutines.Continuation as well. Adding the below rules fixes the issue in the sample for me (note, you should refine the keep rule for the api to only keep what is needed).
-keep class com.example.api.** { *; }
-keep class kotlin.coroutines.Continuation
I will make a pull request on retrofit to add kotlin.coroutines.Continuation
to the rules we consume.
Description
_I found an unexpected payload limit in the Google Forms API.
API Test (Endpoint:
https://docs.google.com/forms/d/e/1FAIpQLSdutBP9XEj60r32iBJ08vlJ6Nh9aMMF9dMajwn1zTalZF4O6g/formResponse
):entry.1545949715
):200
, response recorded in the Responses tab.413 Payload Too Large
, response rejected.413
, response rejected.Stress Test (API):
200
, responses recorded, no rate limiting.Impact: This 32,762-character limit is much lower than expected (e.g., the web interface handles 1 million characters), which can break applications relying on the API for large data submissions (e.g., automated survey tools, data collection scripts). Developers may face failed integrations or data loss.
I’ve also reported this to the VRP (Issue #408326972), but since it’s a functional bug, I’m submitting it here as well for the Google Forms team to review.
Environment: Windows, Python 3 with
requests
library. Steps to Reproduce:https://docs.google.com/forms/d/e/1FAIpQLSdutBP9XEj60r32iBJ08vlJ6Nh9aMMF9dMajwn1zTalZF4O6g/formResponse
with fieldentry.1545949715
. Observe413
status.200
status and response recorded in the Responses tab.I’ve attached screenshots showing the
413
and200
responses. I’m happy to provide more details or run additional tests if needed!