Incorrect value sent to solr

[Łukasz Szczepański]

Error java.lang.NumberFormatException: For input string: "2206267083" I 
got from logs section in solr, it's visible when you expand an error.
NumberFormatException is raised when passed value isn't correct number 
value. Quick tests shows that in this place solr expects signed int.

I know that using uid is not the correct way, but Dovecot seems to be 
doing just that:
https://github.com/dovecot/core/blob/57069b23e6515875796473bdd4ec4bf90343fb25/src/plugins/fts-solr/fts-backend-solr.c#L841

W dniu 2021-04-03 23:15, Shawn Heisey napisał(a):
> On 4/3/2021 12:12 PM, Łukasz Szczepański wrote:
>> Rows isn't part of manage-schema for solr collection its build in 
>> common query parameters in solr, and type of this field cannot be 
>> changed. It controls the number of returned results (by default 10).
>> I still think that an issue on dovecot side, but I was also wrong, 
>> this parameter is important and have to be sent. Dovecot should send a 
>> count of messages in mailbox (or imap folder) not the highest uid in 
>> folder.
> 
> I just tried a query on a stock Solr example with rows set to
> 3000000000 and got an error similar to the one you reported.
> 
> org.apache.solr.common.SolrException: For input string: "3000000000"
> 
> No mention of "int" in this error.  I'm wondering if that part was
> something you added to the email, not text that was actually in the
> error.
> 
> I was using Solr 8.5.1, the newest version I have downloaded right now.
> 
> This error also occurs in cloud mode. With distributed indexes, it
> could be perfectly acceptable to use a rows parameter that exceeds
> what a signed int can hold.  Performance would probably suck when
> using a value that high, but it would be acceptable.  Which smells
> like a bug in Solr.
> 
> I can tell you that using a value from uid in the rows parameter is
> almost certainly not the right thing to do.  That field would have no
> connection to rows.
> 
> Thanks,
> Shawn