Affected module
Backend (openmetadata-service)

Describe the bug

Two related code quality bugs in openmetadata-service that degrade debuggability and leak resources:

Bug 1: FeedRepository.deleteByAbout() silently swallows exceptions

In FeedRepository.java, the deleteByAbout() method has an empty catch block that silently swallows all exceptions during thread deletion:

public void deleteByAbout(UUID entityId) {
    List<String> threadIds = listOrEmpty(dao.feedDAO().findByEntityId(entityId.toString()));
    for (String threadId : threadIds) {
        try {
            deleteThreadInternal(UUID.fromString(threadId));
        } catch (Exception ex) {
            // Continue deletion   ← EXCEPTION SILENTLY SWALLOWED
        }
    }
}

The class already has @Slf4j and uses LOG extensively (debug, warn, info), but this catch block provides zero diagnostic information. When thread deletion fails during entity cleanup, operators have no way to diagnose why orphaned feed data remains.

Impact: Orphaned feed entries silently accumulate with no visibility into root cause. Violates OpenMetadata's logging conventions used throughout the rest of the file.

Bug 2: SchemaFieldExtractor unclosed InputStreams in loadMainSchema() and loadSchema()

In SchemaFieldExtractor.java, both loadMainSchema() and loadSchema() open InputStream via getClassLoader().getResourceAsStream() but never close them:

// loadMainSchema() - line ~167
InputStream schemaInputStream =
    SchemaFieldExtractor.class.getClassLoader().getResourceAsStream(schemaPath);
// ... used but never closed

// loadSchema() - line ~418
InputStream schemaInputStream = getClass().getClassLoader().getResourceAsStream(schemaPath);
// ... used but never closed

Notably, getAllEntityTypes() in the same file correctly uses try-with-resources for its InputStreams, making this inconsistency clearly unintentional.

Impact: Each schema load leaks a file descriptor. During startup or bulk entity type processing, this can exhaust file descriptors and cause hard-to-diagnose failures.

To Reproduce

Bug 1:

1. Create an entity with associated feed threads
2. Trigger deletion of that entity (calls EntityRepository.cleanup() → FeedRepository.deleteByAbout())
3. If any thread deletion fails (e.g., concurrent modification, DB constraint), no log entry is produced
4. Orphaned feed data remains with no diagnostic trail

Bug 2:

1. Call getEntityFields() or resolveSchemaByType() which invoke loadMainSchema() / loadSchema()
2. Each invocation leaks one InputStream (file descriptor)
3. Under heavy schema processing, file descriptor exhaustion can occur

Expected behavior

Bug 1: Failed thread deletions should be logged at WARN level with thread ID, entity ID, and exception details, consistent with the logging conventions used throughout FeedRepository.

Bug 2: InputStreams should be wrapped in try-with-resources blocks, consistent with the pattern already used in getAllEntityTypes() in the same file.

Version:

• OpenMetadata version: main branch (latest)

Additional context
Both bugs are in openmetadata-service and represent straightforward fixes with no behavioral change — just proper resource management and diagnostic logging.