A port typed `~P` reports its type as `P`: the conjugation is lost in the Symbol, query and reflection APIs and in api-json's PortUsage.type
Maintainer thường phản hồi trong vòng 1 ngày
@devin-ai-integration đang làm issue này rồi.
Từ ngày 5/11/2026.
- #1980 của @devin-ai-integration — đang mở
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 20/100
Hướng nghiên cứu
Start with the attached repro.py and model, then trace how conjugated port typing is exposed through Symbol, query, reflection, and api-json. The issue cites docs/project/spec-compliance.md and the SysML and KerML requirements; use the reproduction checks to locate the affected paths and verify each reported type. Done when those routes preserve the conjugated definition and the script’s BUG checks pass; linked pull request #1980 is already open.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
This issue was written with AI help. The model, the reproduction script and its output are
attached and were run against the version below.
Model and observed behaviour
package ConjugatedPorts {
port def CmdPort {
out attribute cmd : ScalarValues::Integer;
}
part def Sender {
port cmdOut : CmdPort; // ordinary typing
}
part def Receiver {
port cmdIn : ~CmdPort; // conjugated typing
}
}
The conjugated port is reported as typed by CmdPort, which makes it indistinguishable from the
ordinary port, in every route a client normally reads:
| Route | cmdIn : ~CmdPort reports |
Expected |
|---|---|---|
Python Symbol (metadata['type'], type_facts, specializations) |
exactly what cmdOut : CmdPort reports: type 'CmdPort', TypeFacts(declared='CmdPort', resolved_id='…::CmdPort'), Specialization(kind='typing', target_id='…::CmdPort'). The ~ is gone even from declared. |
typing by …::CmdPort::~CmdPort, or at least a conjugation marker; declared='~CmdPort' |
model.query type |
ConjugatedPorts::CmdPort |
ConjugatedPorts::CmdPort::~CmdPort |
Reflection PortUsage::type, ::portDefinition |
[ConjugatedPorts::CmdPort] |
[ConjugatedPorts::CmdPort::~CmdPort] |
Reflection ownedTyping.conjugatedPortDefinition, ownedTyping.type |
ExecutionError: reflective feature is not derived: SysML::Systems::ConjugatedPortTyping::conjugatedPortDefinition (same for type) |
[ConjugatedPorts::CmdPort::~CmdPort] |
api-json PortUsage.type |
[CmdPort] |
[CmdPort_conjugated], as its own ConjugatedPortTyping.type says |
Some parts are already right, which shows the model is built correctly underneath:
- The reflected
ConjugatedPortTypingexists, and itsportDefinitionisCmdPort. - api-json writes the typing as a
ConjugatedPortTypingwithtype=conjugatedPortDefinition=
CmdPort_conjugatedandportDefinition=CmdPort, and writes the PortUsage'sportDefinition
anddefinitionasCmdPort_conjugated. OnlyPortUsage.typedisagrees, and the PortUsage
carries a privatesysx:conjugatedTyping: trueflag instead. - The conjugated definition is a symbol (
model.get("ConjugatedPorts::CmdPort::~CmdPort")), but
nothing on the port points to it.
The practical effect: a client reading port types (to check interface compatibility, generate
code, or draw diagrams) cannot tell an input-facing ~CmdPort from an output-facing CmdPort.
$ python repro.py # loads the model with opensysml.loads() over sysml-grpc
[BUG ] cmdIn : ~CmdPort is reported differently from cmdOut : CmdPort
observed: {'metadata.type': 'CmdPort', 'type_facts': TypeFacts(declared='CmdPort', resolved_id='ConjugatedPorts::CmdPort', resolved_kind='portDef', primitive='', primitive_source='', quantity=False, unit=''), 'specializations': [Specialization(kind='typing', declared='CmdPort', target_id='ConjugatedPorts::CmdPort', target_kind='portDef')]}
[BUG ] query 'type' of cmdIn is the conjugated definition
observed: 'ConjugatedPorts::CmdPort'
[BUG ] PortUsage::type of cmdIn is the conjugated definition
observed: ['ConjugatedPorts::CmdPort']
[BUG ] PortUsage::portDefinition of cmdIn is the conjugated definition
observed: ['ConjugatedPorts::CmdPort']
[OK ] ConjugatedPortTyping::portDefinition is the original definition
observed: ['ConjugatedPorts::CmdPort']
[BUG ] ConjugatedPortTyping::conjugatedPortDefinition is the conjugated definition
observed: ExecutionError('evaluation failed: reflective feature is not derived: SysML::Systems::ConjugatedPortTyping::conjugatedPortDefinition for ')
[BUG ] ConjugatedPortTyping::type is the conjugated definition
observed: ExecutionError('evaluation failed: reflective feature is not derived: SysML::Systems::ConjugatedPortTyping::type for ')
[INFO] api-json: the port's typing relationship (correct)
observed: {'@type': 'ConjugatedPortTyping', 'type': {'@id': 'ConjugatedPorts__CmdPort_conjugated'}, 'conjugatedPortDefinition': {'@id': 'ConjugatedPorts__CmdPort_conjugated'}, 'portDefinition': {'@id': 'ConjugatedPorts__CmdPort'}}
[BUG ] api-json: PortUsage.type agrees with its ConjugatedPortTyping.type
observed: [{'@id': 'ConjugatedPorts__CmdPort'}]
expected: [{'@id': 'ConjugatedPorts__CmdPort_conjugated'}]
Reproduction files (attached)
| File | Contents |
|---|---|
model.sysml.txt |
the model above (GitHub does not accept .sysml uploads): rename it to model.sysml next to repro.py |
repro.py |
loads model.sysml with opensysml.loads() and checks the Symbol, query, reflection and api-json routes. Each check prints OK, BUG or INFO, and the script exits 1 while any BUG reproduces. |
_common.py |
shared helper repro.py imports: starts the sysml-grpc named by $OPENSYSML_BINARY, prints the server and client versions, and formats the checks |
output.txt |
the full output of the run reported here |
To run it, put _common.py in the parent directory of the folder holding repro.py and
model.sysml, install the client (pip install -e client/python), and point
OPENSYSML_BINARY at a sysml-grpc build:
$ OPENSYSML_BINARY=/path/to/OpenSysML/bin/sysml-grpc python repro.py
Without OPENSYSML_BINARY, _common.py assumes the layout used here: an OpenSysML checkout
next to the directory that holds _common.py, with bin/sysml-grpc built by make build-grpc.
What the specification requires
SysML v2.1 Beta 2, §8.3.12.3 ConjugatedPortTyping:
A ConjugatedPortTyping is a FeatureTyping whose type is a ConjugatedPortDefinition.
conjugatedPortDefinition : ConjugatedPortDefinition {redefines type}— The type of this
ConjugatedPortTyping considered as a FeatureTyping, which must be a ConjugatedPortDefinition.
/portDefinition : PortDefinition— The originalPortDefinition of the conjugatedPortDefinition
of this ConjugatedPortTyping.
So for port cmdIn : ~CmdPort, the typing's type (= conjugatedPortDefinition) is
CmdPort::'~CmdPort', and only the derived portDefinition of the typing is CmdPort.
conjugatedPortDefinition is not a derived property, so "reflective feature is not derived" is
the wrong answer for it in any case.
KerML v1.1 Beta 2, deriveFeatureType: "The types of a Feature are the union of the types of
its typings and the types of the Features it subsets", so cmdIn.type is CmdPort::'~CmdPort'.
PortUsage::portDefinition (the port's definitions) is then that ConjugatedPortDefinition too,
which is what api-json already writes for portDefinition and definition.
The project's compliance record states the same (docs/project/spec-compliance.md,
conjugated-port row, ✅ Faithful): "port p : ~P types a port by the conjugated port definition
P::'~P' (§7.12.3)". The direction reversal that row describes does work. The reported type
does not follow it.
For the Python Symbol facts, which the specification does not define, the natural equivalent
is type_facts.resolved_id / Specialization.target_id = …::CmdPort::~CmdPort (with
declared='~CmdPort'), or an explicit conjugation flag next to the original definition.
Kind of gap
Parsed or resolved into the wrong structure
Reference implementation
Not tried.
Version
sysml-grpc v0.12.0-262-gc86932321 (develop at c86932321), opensysml Python client 0.12.0, Python 3.13.15
- Ngôn ngữ chính
- Go
- Star
- 56
- Fork
- 17
- Merge trung bình
- 12 giờ 50 phút
- Pull request đã merge (30 ngày)
- 905
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Open-MBEE/OpenSysML
-
dependencies
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Open-MBEE/OpenSysML#1951 · 3 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug spec compliance
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 43/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug spec compliance
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Open-MBEE/OpenSysML#2033 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Open-MBEE/OpenSysML#2029 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Open-MBEE/OpenSysML
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
nebari-dev/nebi#652 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
type:bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
nightgauge/nightgauge#3077 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
debug-adapter language server
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
open-policy-agent/regal#2161 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày