Apicurio-studio: コラボレーション中のAPI変更の問題の保存

それは良いことではありません。 どのバージョンのApicurioを使用していますか？ これはクラウドバージョンで発生していますか、それともローカルで実行していますか？ 私は最近、このような問題を見つけて修正しました（ただし、 SHARE_FOR_EVERYONE機能を使用している場合のみ）が、最新バージョンを使用しているか、その機能を使用していない場合、これは新しいバグである可能性があります。

最新バージョン0.243.finalがkubernetesで実行されており、SHARE_FOR_EVERYONEがアクティブ化されています。

@EricWittmannに迅速にご連絡いただき、ありがとうございます。
不思議なことに、変更はリロード後に永続的ではありませんが、アクティビティログに表示されます。
うまくいけば、@ t-rapはすぐにデータベースを見ることができます。

おい、

返事が遅くなってごめん：

Dockerハブを介して提供するDockerイメージを使用して、kubernetesでapicurio-studioを実行しています。
そう
Apicurio-studio-ui、-ws、-api、-db（画像：percona：5.7）

開発者がこれを使用する場合、apicurio-studio-apiのデバッグメッセージは次のとおりです。

2019-11-20 15:12:05,053 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-66) Selecting the most recent api_content row of type 'document' for: 12 2019-11-20 15:12:05,056 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-66) Inserting an Editing Session UUID row: REDACTED 2019-11-20 15:12:05,070 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-66) Created Session ID: REDACTED 2019-11-20 15:12:05,070 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-66) Secret: REDACTED 2019-11-20 15:12:14,973 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-66) Retrieving contributors list for design with ID: 12 2019-11-20 15:12:14,973 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-66) Selecting all contributors for API Design: 12 2019-11-20 15:12:14,973 DEBUG [io.apicurio.studio.shared.config.Configuration] (default task-65) Config Property: APICURIO_SHARE_FOR_EVERYONE/apicurio.share.for.everyone = true 2019-11-20 15:12:14,973 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-65) Selecting activity for API Design: 12 from 0 to 10 2019-11-20 15:12:14,983 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-64) Selecting mock activity for API Design: 12 from 0 to 20 2019-11-20 15:12:14,997 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Getting an API design with ID 12 2019-11-20 15:12:14,997 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Selecting a single API Design: 12 2019-11-20 15:12:17,810 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Getting an API design with ID 12 2019-11-20 15:12:17,810 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Selecting a single API Design: 12 2019-11-20 15:12:17,860 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Editing an API Design with ID 12 2019-11-20 15:12:17,860 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) USER: REDACTED 2019-11-20 15:12:17,860 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Selecting the most recent api_content row of type 'document' for: 12 2019-11-20 15:12:17,862 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Inserting an Editing Session UUID row: REDACTED 2019-11-20 15:12:17,875 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Created Session ID: REDACTED 2019-11-20 15:12:17,875 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Secret: REDACTED

apicurio-studio-wsの場合：

2019-11-20 15:14:31,640 DEBUG [io.apicurio.hub.core.editing.ops.processors.CommandProcessor] (default task-3) user: REDACTED 2019-11-20 15:14:31,640 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-3) Inserting a 'command' content row for: 12 2019-11-20 15:14:31,659 DEBUG [io.apicurio.hub.core.editing.ops.processors.CommandProcessor] (default task-3) ACK sent back to client. 2019-11-20 15:14:31,659 DEBUG [io.apicurio.hub.core.editing.ops.processors.CommandProcessor] (default task-3) Command propagated to 'other' clients. 2019-11-20 15:14:33,145 DEBUG [io.apicurio.hub.core.editing.ops.processors.OperationProcessorDispatcher] (default task-3) Received a "ping" message/operation from a client for API Design: 12 2019-11-20 15:14:44,989 DEBUG [io.apicurio.hub.core.editing.ops.processors.OperationProcessorDispatcher] (default task-3) Received a "ping" message/operation from a client for API Design: 15 2019-11-20 15:14:46,691 DEBUG [io.apicurio.hub.editing.EditApiDesignEndpoint] (default task-3) Closing a WebSocket due to: 2019-11-20 15:14:46,692 DEBUG [io.apicurio.hub.editing.EditApiDesignEndpoint] (default task-3) designId: 12

したがって、これは間違いなく最近修正したバグでした。最新のリリース後に修正した可能性があります。 それを確認して、ここで返信します。

OKこの問題の修正は、最新のリリース後に行われたことを確認しました。 したがって、これを修正するには2つのオプションがあります。

1）次のリリースを待つ
2）マスターから最新のものをビルドし、それを実行します

オプション（2）はおそらくあなたが思っているよりもアクセスしやすいですが、それでも明らかにあなたにとって理想的ではありません。 おそらく週末に別のリリースを行うことができます。 リリースをトリガーする前に無効にする（または少なくともUIでそのようにマークする）必要がある実験的な機能がいくつか追加されています。

私は今、新しいリリースを開始しています-この問題の修正が含まれます。 リリースノートに含まれるように、クローズとしてマークします。 :)

こんにちはエリック、

問題はまだあるようですが、今は例外をスローします。 それが私たちのせいなのかどうかはわかりません。 私がそれをより深く調べることができるヒントはありますか？

`` `2019-11-22 10：16：14,057エラー[io.apicurio.hub.core.storage.jdbc.JdbcStorage]（デフォルトのタスク-1）最新のコンテンツドキュメントの取得中にエラーが発生しました：java.lang.IllegalStateException：1つの要素が必要です、しかし何も見つかりませんでした
org.jdbi.v3.core.result.ResultIterable.one（ResultIterable.java:135）で
io.apicurio.hub.core.storage.jdbc.JdbcStorage.lambda $ getLatestContentDocument $ 23（JdbcStorage.java:655）で
org.jdbi.v3.core.Jdbi.withHandle（Jdbi.java:341）で
io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument（JdbcStorage.java:648）で
io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument（不明なソース）
io.apicurio.hub.core.storage.RollupExecutor.rollupCommands（RollupExecutor.java:56）で
io.apicurio.hub.core.storage.RollupExecutor.rollupCommands（RollupExecutor.java:108）で
io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands（不明なソース）
io.apicurio.hub.core.editing.EditingSession.close（EditingSession.java:131）で
io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession（EditingSessionManager.java:116）で
io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession（不明なソース）
io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession（EditApiDesignEndpoint.java:215）で
sun.reflect.NativeMethodAccessorImpl.invoke0（ネイティブメソッド）で
sun.reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:62）で
sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）で
java.lang.reflect.Method.invoke（Method.java:498）で
io.undertow.websockets.jsr.annotated.BoundMethod.invoke（BoundMethod.java:87）で
io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run（AnnotatedEndpoint.java:201）で
io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call（ServerWebSocketContainer.java:169）で
io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call（ServerWebSocketContainer.java:166）で
io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call（ContextClassLoaderSetupAction.java:43）で
org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0（SecurityContextThreadSetupAction.java:105）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod（ServerWebSocketContainer.java:603）で
io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run（ServerWebSocketContainer.java:589）で
io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run（OrderedExecutor.java:67）で
org.jboss.threads.ContextClassLoaderSavingRunnable.run（ContextClassLoaderSavingRunnable.java:35）で
org.jboss.threads.EnhancedQueueExecutor.safeRun（EnhancedQueueExecutor.java:1985）で
org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask（EnhancedQueueExecutor.java:1487）で
org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run（EnhancedQueueExecutor.java:1378）で
java.lang.Thread.run（Thread.java:748）で

2019-11-22 10：16：14,057エラー[io.apicurio.hub.core.editing.EditingSession]（デフォルトのタスク-1）編集セッションを閉じるときにエラーが検出されました：io.apicurio.hub.core.exceptions.NotFoundException
io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument（JdbcStorage.java:659）で
io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument（不明なソース）
io.apicurio.hub.core.storage.RollupExecutor.rollupCommands（RollupExecutor.java:56）で
io.apicurio.hub.core.storage.RollupExecutor.rollupCommands（RollupExecutor.java:108）で
io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands（不明なソース）
io.apicurio.hub.core.editing.EditingSession.close（EditingSession.java:131）で
io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession（EditingSessionManager.java:116）で
io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession（不明なソース）
io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession（EditApiDesignEndpoint.java:215）で
sun.reflect.NativeMethodAccessorImpl.invoke0（ネイティブメソッド）で
sun.reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:62）で
sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）で
java.lang.reflect.Method.invoke（Method.java:498）で
io.undertow.websockets.jsr.annotated.BoundMethod.invoke（BoundMethod.java:87）で
io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run（AnnotatedEndpoint.java:201）で
io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call（ServerWebSocketContainer.java:169）で
io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call（ServerWebSocketContainer.java:166）で
io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call（ContextClassLoaderSetupAction.java:43）で
org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0（SecurityContextThreadSetupAction.java:105）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0（UndertowDeploymentInfoService.java：1502）で
io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod（ServerWebSocketContainer.java:603）で
io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run（ServerWebSocketContainer.java:589）で
io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run（OrderedExecutor.java:67）で
org.jboss.threads.ContextClassLoaderSavingRunnable.run（ContextClassLoaderSavingRunnable.java:35）で
org.jboss.threads.EnhancedQueueExecutor.safeRun（EnhancedQueueExecutor.java:1985）で
org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask（EnhancedQueueExecutor.java:1487）で
org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run（EnhancedQueueExecutor.java:1378）で
java.lang.Thread.run（Thread.java:748） `` `で

これは、バグ修正がなかった場合に予想されるエラーであると確信しています。 コードへのリンクをいくつか掘り下げてみましょう...

わかりました、私はあなたの時間を無駄にしないようにチェックしました、しかしそれは最終バージョンのようです：

バージョン| 0.2.44。ファイナル
-| -
構築| 2019年11月21日
エディション| CLIv7
プロジェクトのURL | http://www.apicur.io/

すでに存在する古いAPIをテストし、新しいAPIを作成してテストし、さまざまなアカウントで試しました。

OKありがとう。 したがって、そのスタックトレースで何が起こっているかというと、APIのすべてのエディターが編集（エディターを離れる/閉じる）が完了するたびに、サーバーはすべての変更をドキュメントスナップショットにロールアップしようとします。 これは、ロールアップエグゼキュータによって次のように実行されます。

https://github.com/Apicurio/apicurio-studio/blob/master/back-end/hub-core/src/main/java/io/apicurio/hub/core/storage/RollupExecutor.java

これを行おうとしています：

1）最後のドキュメントスナップショットを取得します
2）それ以降のすべての変更（コマンド）のリストを取得します
3）すべての変更/コマンドを最後のドキュメントスナップショットに適用します
4）新しいスナップショットをDBに保存します

前のスナップショットが見つからないため、手順1で失敗します。 APIデザインが最初に作成されたときにスナップショットが作成されるため、これは不可能なはずです。 ただし、これはおそらく、「全員共有」オプションが-api Apicurioコンポーネントで有効になっているが、-wsApicurioコンポーネントでは有効になっていないために発生しています。 したがって、元のスナップショットはテーブルに存在しますが、ユーザーAによって作成されたため、ユーザーBがロールアップを実行しようとすると（そして全員共有が無効になっている場合）、スナップショットの検索時に間違ったSQLが実行され、見つかりません。 したがって、-ws apicurioコンポーネントでのみ共有機能の構成が誤っているため、このコードが正しく機能していない可能性があります。

https://github.com/Apicurio/apicurio-studio/blob/master/back-end/hub-core/src/main/java/io/apicurio/hub/core/storage/jdbc/JdbcStorage.java#L650- L655

share-for-everyoneが-apiで有効になっているが、-wsが有効になっていない場合、これが発生します。

kubernetesの設定を確認する必要があります（補足：貢献したい場合はありますか？）が、dockerのcompose構成に基づいている場合は、全員共有が欠落していると思います。 -wsコンポーネントのconfigオプション。 この問題の主な修正の1つは次のとおりです。

https://github.com/Apicurio/apicurio-studio/commit/7f4994bc907e1720ffd6f8ff81e844c032edbf79#diff -b1ff2c3381198f745ae9dc8add793d61

ねえエリック、

ヒントをありがとう。 -wsポッドにもshare-for-everyoneを設定することで、問題を「修正」しました。 https://hub.docker.com/r/apicurio/apicurio-studio-wsでオプションとして表示されませんでした

必要に応じて、k8s-configsをクリーンアップし、プルリクエストを送信します。 私は来週の初めまでそれを成し遂げることができると思います。

素晴らしい！ その画像のドキュメントを更新して、そのオプションを含めます。 k8sの設定を急ぐ必要はありませんが、貢献は大歓迎です。