I’m trying to test scanning a new repo and getting a “Visit of Component failed” error in the background tasks, with what looks like a value too long for column BINARY VARYING
error as the root cause:
### Error updating database. Cause: org.apache.ibatis.type.TypeException: Could not set parameters for mapping: ParameterMapping{property='dto.data', mode=IN, javaType=class java.lang.Object, jdbcType=BINARY, numericScale=null, resultMapId='null', jdbcTypeName='null', expression='null'}. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.h2.jdbc.JdbcSQLDataException: Value too long for column "BINARY VARYING": "313d313b323d313b333d313b343d313b353d313b363d313b373d313b383d313b393d313b31303d31... (1361448)" [22001-210]
### The error may exist in org.sonar.db.measure.LiveMeasureMapper
### The error may involve org.sonar.db.measure.LiveMeasureMapper.insert-Inline
### The error occurred while setting parameters
### Cause: org.apache.ibatis.type.TypeException: Could not set parameters for mapping: ParameterMapping{property='dto.data', mode=IN, javaType=class java.lang.Object, jdbcType=BINARY, numericScale=null, resultMapId='null', jdbcTypeName='null', expression='null'}. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.h2.jdbc.JdbcSQLDataException: Value too long for column "BINARY VARYING": "313d313b323d313b333d313b343d313b353d313b363d313b373d313b383d313b393d313b31303d31... (1361448)" [22001-210]
Versions:
SonarQube 9.4 from docker hub (docker run sonarqube:latest
)
SonarScanner 4.7.0.2747-windows
The problematic file is a very large XML file (>160k lines, almost 10MB), and I have no need to include it but adding it to sonar.exclusions
has had no effect. Sonarqube still tries to “visit” it despite the exclusion. I have even tried deleting the project and starting from scratch. Previous posts about the “Visit of component failed” error have suggested something corrupt in the database, but this is fresh from docker, so I wouldn’t expect any funny business there. (This will eventually go into a properly hosted enterprise edition, but I’m testing the project settings locally first).
If I “implicitly” exclude the file by instead setting sonar.sources to every folder in the repo except the one where that XML lives, the scan is successful. And of course if I delete it from the repo entirely, the scan is successful. Obviously, neither of these are good solutions.
Any thoughts how to get around this, given that excluding the file doesn’t seem to have worked?