[GRDM-62502] 20250906からのアップグレード失敗とWEKO登録時の500エラーを修正 - #779
Draft
yacchin1205 wants to merge 3 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
2件の不具合を修正します。
1. 20250906 のデータベースからのアップグレードで migration が失敗する
osf.0267_split_name_fieldsの適用中にdjango.db.utils.ProgrammingError: column osf_osfuser.ial does not existで失敗し、アップグレードが完了しません。#777 のialプロパティ追加前に267, 270のmigrationを適用していれば、本問題は発生しません。0267 は data migration の中で現行モデルの
FileMetadata.save()を呼んでおり、その save() が検索インデックスの更新を誘発してFileMetadata.creator(現行のOSFUserモデル)を参照します。migration の途中ではosf_osfuserは 0267 時点のスキーマのままなので、それ以降に追加された列(今回は #777 のial)を参照した時点で落ちます。このため 0267 より後に
osf_osfuserへ列を追加するたびに、過去バージョンからのアップグレードが遡って壊れます。FileMetadataのレコードが存在する環境でのみ発生し、レコードが無い新規構築では発生しません。同じ実装を使うosf.0270_remove_metadata_access_rightsも同様です。2. WEKO へのメタデータ登録が「エラーが発生しました: INTERNAL SERVER ERROR」で終わることがある
登録操作の後、進捗を取得する
weko_get_publishing_fileが 500 を返し、画面にエラーダイアログが表示されて登録完了の表示に進みません。サーバ側はKeyError: 'progress'で失敗しています。進捗取得は
AsyncResult.infoを複数回参照していますが、infoは参照のたびに celery のバックエンドへ問い合わせるため、タスクが進行中の間は参照ごとに内容が変わります(celery は完了状態になるまで結果をキャッシュしません)。'progress' in aresult.infoで判定した後、aresult.info['progress']を取り出す前にタスクが完了へ遷移すると、infoの中身が進捗({'progress': ...})から結果({'result': ...})に変わり、キーが存在しなくなります。画面は進捗を毎秒ポーリングしており、登録が成功する瞬間にこの遷移を引くと失敗します。同じ実装が
_get_publishing_project_metadata_progress、および Metadata アドオンのget_task_result/metadata_get_importing_datasetにもあります。Changes
RunPythonに渡されるappsをFileMetadataMigratorへ引き渡すFileMetadataMigratorが historical model(apps.get_model)で対象を取得・保存するように変更。現行モデルのsave()を経由しないため、検索インデックスの更新も走らない_resolve_deposit_taskに集約し、stateとinfoを1度だけ取得した値で判定するAsyncResultの複数回参照を解消(get_task_resultはinfoを最大9回参照していた)_resolve_deposit_taskのテストを追加。進行中・完了・失敗に加え、判定と取り出しの間で完了へ遷移する場合を含むQA Notes
Documentation
None
Side Effects
stateとinfoがごくわずかに異なる時点の値になる場合がありますが、いずれも表示のみに使用されますTicket
GRDM-62502