🐛 Fixes error while updated study with long description

[pcrespov]

What do these changes do?

Fixes error produced when the user updates a study with a long description. After these changes very long descriptions (>1000 chars) and titles (>200 chars) will be truncated without reporting an error. Note that these truncation only happens for input strings in the API. As a general rule all input data to the API should be constrained either with a hard error or silently (e.g. truncating).

As a side note, the front-end should have reacted better to a 4XX errors provided that is a client error (the description maximum length was surpassed). I believe changes like #5487 should help in this direction .

Related issue/s

• resolves Study description: remove characters limits #5988

How to test

• Driving test -k test_project_patch_truncates_description

Dev-ops checklist

None

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.4%. Comparing base (cafbf96) to head (7f97af2).
Report is 293 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #5989      +/-   ##
=========================================
+ Coverage    84.5%   88.4%    +3.8%     
=========================================
  Files          10    1161    +1151     
  Lines         214   50767   +50553     
  Branches       25     562     +537     
=========================================
+ Hits          181   44902   +44721     
- Misses         23    5739    +5716     
- Partials       10     126     +116     

Flag	Coverage Δ
integrationtests	64.7% <ø> (?)
unittests	86.2% <100.0%> (+1.6%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...c/models_library/api_schemas_webserver/projects.py	100.0% <100.0%> (ø)
...s/models-library/src/models_library/basic_types.py	98.4% <100.0%> (ø)
...core_service_api_server/api/routes/studies_jobs.py	92.3% <100.0%> (ø)

... and 1150 files with indirect coverage changes

[elisabettai]

Thanks for the quick fix!

Just a curiosity: you moved the issue from the osparc-issues repo to the osparc-simcore repo. Is there a particular reason?

[odeimaiz]

Instead of setting this limitation in the API, shouldn't it be part of the Project model?

[pcrespov]

Thanks for the quick fix!

Just a curiosity: you moved the issue from the osparc-issues repo to the osparc-simcore repo. Is there a particular reason?

@elisabettai I hope it is ok with you. I did it because:

1. it is a but in osparc-simcore code
2. it automatically gets in my list if it is in osparc-simcore

[pcrespov]

Instead of setting this limitation in the API, shouldn't it be part of the Project model?

@odeimaiz Some clarifications
1. This constrained type is only used so far in the description field of service-metadata (sorry! mistake)!
2. It is only used in the model used for the PATCH body, i.e. it is an input model, not an output. Therefore, once the data is in the system, I do not see a reason to truncate it again.

let me know if this is not clear or I misunderstood your question. We can talk offline

[odeimaiz]

Instead of setting this limitation in the API, shouldn't it be part of the Project model?

@odeimaiz Some clarifications 1. This constrained type is only used so far in the description field of service-metadata (sorry! mistake)! 2. It is only used in the model used for the PATCH body, i.e. it is an input model, not an output. Therefore, once the data is in the system, I do not see a reason to truncate it again.

let me know if this is not clear or I misunderstood your question. We can talk offline

PATCH description and PUT project, isn't it? the PUT call is still used when the study is open.

[pcrespov]

project

Yes both. Sorry, for some reason I thought I used this in metadata descriptions

[elisabettai]

Thanks for the quick fix!
Just a curiosity: you moved the issue from the osparc-issues repo to the osparc-simcore repo. Is there a particular reason?

@elisabettai I hope it is ok with you. I did it because:

1. it is a but in osparc-simcore code

2. it automatically gets in my list if it is in osparc-simcore

Thanks for explaining @pcrespov, it's not a big deal, but for the future I'd leave it in osparc-issues, for the following reasons:

1. It is a bug that "real" (i.e. non-dev) users experience (even external users of osparc.io, lite, sim4life.io, etc.)
2. We use the osparc-issues repo (in particular the special tags "Feedback" and "type:*" to provide metrics for NIH regarding user issues.