[server] KV tablet should not produce log via PRODUCE_LOG

[caozhen1937]

Purpose

Linked issue: close #2750

Brief change log

Tests

API and Format

Documentation

[Copilot]

Pull request overview

Addresses #2750 by preventing PRODUCE_LOG from being accepted on primary-key (KV) tables (and likewise preventing PUT_KV on log tables), returning protocol-level errors instead of attempting the operation.

Changes:

• Add table-type validation for produceLog / putKv in TabletService with explicit per-bucket error responses.
• Add replica-side guards in ReplicaManager to reject PRODUCE_LOG on PK tables and PUT_KV on log tables.
• Add IT/UT coverage to verify the new error codes/messages for wrong-table operations.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
fluss-server/src/main/java/org/apache/fluss/server/tablet/TabletService.java	Early table-type checks for PRODUCE_LOG and PUT_KV; builds explicit error responses.
fluss-server/src/main/java/org/apache/fluss/server/replica/ReplicaManager.java	Replica-side validation to prevent appending/putting to the wrong tablet type.
fluss-server/src/test/java/org/apache/fluss/server/tablet/TabletServiceITCase.java	Integration tests for PRODUCE_LOG on PK tables and PUT_KV on log tables.
fluss-server/src/test/java/org/apache/fluss/server/replica/ReplicaManagerTest.java	Unit test verifying PRODUCE_LOG on PK table returns INVALID_TABLE error.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

InvalidTableException / NonPrimaryKeyTableException thrown here will be treated as “unexpected” by isUnexpectedException(...), which will still emit an ERROR log + increment failed-request metrics for this expected client misuse. Consider updating isUnexpectedException (or the catch block logic) to treat these table-type validation exceptions as expected so PRODUCE_LOG/PUT_KV on the wrong table type doesn’t produce error logs.

[Copilot]

Same as above: throwing NonPrimaryKeyTableException here will currently be logged at ERROR as an “unexpected” exception. To align with the PR goal (avoid noisy logs for wrong-table operations), add this exception to the expected list in isUnexpectedException(...) (or handle ApiException separately) so the server doesn’t log stack traces for this case.