Wouldn't it be better if the extension developer adapts the extension?

To replicate your scenario, I have adjusted the table #__contact_details in line with the details you provided in the issue.

checked_out | int | no Default | not NULL

I had to work a bit of a workaround here in the store function, as the Joomla core doesn’t naturally support this.

      if (empty($this->checked_out)) {
           $this->checked_out    = 0;
        }

As you can see here, the incorrect configuration for the column is neatly caught in the try-catch block and is later marked as unsuccessful in the task result, accompanied by a warning sign.

The page is not broken and the error is highlighted as intended.
I regard this as the expected behaviour, and the column in the component should be adapted to match the conventions used in the two core components. Otherwise, it may lead to unwanted surprises, as is the case here.

Unfortunately, I was unable to reproduce the uncaught mysqli_sql_exception that you are describing.

To replicate your scenario, I have adjusted the table #__contact_details in line with the details you provided in the issue.

checked_out | int | no Default | not NULLABLE

I had to work a bit of a workaround here in the store function, as the Joomla core doesn’t naturally support this.

      if (empty($this->checked_out)) {
           $this->checked_out    = 0;
        }

As you can see here, the incorrect configuration for the column is neatly caught in the try-catch block and is later marked as unsuccessful in the task result, accompanied by a warning sign.

The page is not broken and the error is highlighted as intended.
I regard this as the expected behaviour, and the column in the component should be adapted to match the conventions used in the two core components. Otherwise, it may lead to unwanted surprises, as is the case here.

Unfortunately, I was unable to reproduce the uncaught mysqli_sql_exception that you are describing.

To replicate your scenario, I have adjusted the table #__contact_details in line with the details you provided in the issue.

I had to work a bit of a workaround here in the store function, as the Joomla core doesn’t naturally support this.

      if (empty($this->checked_out)) {
           $this->checked_out    = 0;
        }

As you can see here, the incorrect configuration for the column is neatly caught in the try-catch block and is later marked as unsuccessful in the task result, accompanied by a warning sign.

The page is not broken and the error is highlighted as intended.
I regard this as the expected behaviour, and the column in the component should be adapted to match the conventions used in the two core components. Otherwise, it may lead to unwanted surprises, as is the case here.

Unfortunately, I was unable to reproduce the uncaught mysqli_sql_exception that you are describing.

Quite right that the fix for the checkout column is easily fixed in components table. The issue is probable not the checkin task but incomplete error handling in MysqliStatement, so the issue can be closed here.

Steps to reproduce:

CREATE TABLE #__checkout(idint(10) unsigned NOT NULL AUTO_INCREMENT,checked_outint(10) unsigned NOT NULL,checked_out_time datetime DEFAULT NULL, PRIMARY KEY (id) )

Now execute the Global Check-in task, The task while fail with a 'No content was returned' and the response will have a message "Field 'checked_out' doesn't have a default value.'

This is the result/message of a mysqli_sql_exception in the constructor of MysqliStatement. There the $this->statement is checked and it throws a PrepareStatementFailureException if it is not set, but does not catch and convert exceptions from $connection->prepare

` public function __construct(\mysqli $connection, string $query)
{
$this->connection = $connection;
$this->query = $query;

    $query = $this->prepareParameterKeyMapping($query);
   // try {  
    $this->statement  = $connection->prepare($query);
  // } catch(....) {
 // throw new PrepareStatementFailureException($this->connection->error, $this->connection->errno);

//}
if (!$this->statement) {
throw new PrepareStatementFailureException($this->connection->error, $this->connection->errno);
}
}
`

Thanks for the additional explanation. I’ll give that a new try later. If we can improve our error handling here, I think we should definitely give it a go.