Skip to content

Add implementation to update service settings method for AI21 service#142597

Merged
Jan-Kazlouski-elastic merged 4 commits intoelastic:mainfrom
Jan-Kazlouski-elastic:implement-update-service-settings-method-ai-21
Feb 19, 2026
Merged

Add implementation to update service settings method for AI21 service#142597
Jan-Kazlouski-elastic merged 4 commits intoelastic:mainfrom
Jan-Kazlouski-elastic:implement-update-service-settings-method-ai-21

Conversation

@Jan-Kazlouski-elastic
Copy link
Copy Markdown
Contributor

@Jan-Kazlouski-elastic Jan-Kazlouski-elastic commented Feb 17, 2026

This PR is a part of a broader initiative related to endpoint _update operation: #122356
In particular - this PR provides implementation for updateServiceSettings method used in _update operation.
Initially the changes present in this PR were a part of a bigger PR #140082, but following @jonathan-buttner's request a smaller PR was created in order to simplify the review process.
API reference for the update operation can be found here: https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-inference-update

Currently Service Settings updateServiceSettings method being called during endpoint update operation is implemented only for GoogleVertexAiEmbeddingsServiceSettings and ElasticsearchInternalServiceSettings.
This PR makes changes to these existing method implementations with minor refactoring, also providing the new method implementation for AI21 service.
Default implementation in ServiceSettings interface still returns unchanged this instance. This is done in order to avoid making changes to every provider at once.
CustomServiceSettings require taskType parameter so it was added to the method signature.

model_id field in AI21 request service settings map is immutable, meaning it cannot be updated with _update operation. Decision was made here: #140082 (comment)

Since this was previously a part of a bigger PR with a lot of refactoring - some of this refactoring is present here as well.

  • - Have you signed the contributor license agreement?
  • - Have you followed the contributor guidelines?
  • - If submitting code, have you built your formula locally prior to submission with gradle check?
  • - If submitting code, is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed.
  • - If submitting code, have you checked that your submission is for an OS and architecture that we support?
  • - If you are submitting this code for a class then read our policy for that.

@elasticsearchmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/search-inference-team (Team:Search - Inference)

* @return the updated service settings
*/
default ServiceSettings updateServiceSettings(Map<String, Object> serviceSettings, TaskType taskType) {
return this;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping this default implementation as is in order to avoid having to implement for every service at once

);

Model mergedParsedModel = service.get().buildModelFromConfigAndSecrets(mergedModelConfigurations, mergedModelSecrets);
if (mergedParsedModel.equals(existingParsedModel)) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was requested by @DonalEvans here: #140082 (comment)

* @param taskType the task type for which the service settings are being updated
* @return the updated service settings
*/
default ServiceSettings updateServiceSettings(Map<String, Object> serviceSettings, TaskType taskType) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding TaskType param in order to support the Custom Service Settings

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than changing this interface, would it be possible to add a TaskType field to CustomServiceSettings that gets set when they're first created? Task type is not something that can be updated, so it seems like it should be safe to copy the task type from the old settings into the new settings when doing an update.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good idea. Made the change in the original PR . I believe it would work. Removed changes related to Custom Service from this PR.


// Rate limit for AI21 is 10 requests / sec or 200 requests / minute. Setting default to 200 requests / minute
protected static final RateLimitSettings DEFAULT_RATE_LIMIT_SETTINGS = new RateLimitSettings(200);
private static final RateLimitSettings DEFAULT_RATE_LIMIT_SETTINGS = new RateLimitSettings(200);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not used outside of this class so there's no need in keeping it protected.


var extractedRateLimitSettings = RateLimitSettings.of(
serviceSettings,
this.rateLimitSettings,
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using existing RateLimitSettings as default value

config.getTaskType(),
config.getService(),
ConfigurationParseContext.PERSISTENT
ConfigurationParseContext.REQUEST
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usage of REQUEST instead of PERSISTENT allows RateLimitSettings to be validated during model creation and makes more sense semantically.


@Override
public ServiceSettings updateServiceSettings(Map<String, Object> serviceSettings) {
public ServiceSettings updateServiceSettings(Map<String, Object> serviceSettings, TaskType taskType) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No changes to behavior, just minor refactoring and updating the param set

serviceSettings = new HashMap<>(serviceSettings);

Integer maxBatchSize = ElasticInferenceServiceSettingsUtils.parseMaxBatchSize(serviceSettings, validationException);
var extractedMaxBatchSize = ElasticInferenceServiceSettingsUtils.parseMaxBatchSize(serviceSettings, validationException);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Existing variable name hides the class field. That's bad practice.

}

var numAllocations = extractOptionalPositiveInteger(
var extractedNumAllocations = extractOptionalPositiveInteger(
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same issue with existing variable name hiding the class field

verifyNoModelRegistryMutations();
}

public void testMasterOperation_UpdatedModelIsEqualToExistingModel_ValidationAndUpdateIsSkipped() {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New test to check early return logic

assertThat("update should create a new instance", updatedInstance, not(equalTo(testInstance)));
assertThat(updatedInstance.getClass(), equalTo(testInstance.getClass()));
assertThat(updatedInstance, instanceOf(ElasticsearchInternalServiceSettings.class));
var updatedElasticSearchInternalServiceSettings = (ElasticsearchInternalServiceSettings) updatedInstance;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is caused by the fact that ElasticsearchInternalServiceSettings now returns ElasticsearchInternalServiceSettings and there's no need in such casting

@Jan-Kazlouski-elastic
Copy link
Copy Markdown
Contributor Author

Hi @DonalEvans
Would you give this PR another look? I removed changes caused by Custom Service. Now it should be even easier to review.

@Jan-Kazlouski-elastic Jan-Kazlouski-elastic merged commit 6e5f1a8 into elastic:main Feb 19, 2026
37 checks passed
@Jan-Kazlouski-elastic Jan-Kazlouski-elastic deleted the implement-update-service-settings-method-ai-21 branch April 2, 2026 09:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

external-contributor Pull request authored by a developer outside the Elasticsearch team :SearchOrg/Inference Label for the Search Inference team Team:Search - Inference >tech-debt v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants